FHEM Adapter

[ioB_Daniel]

@DJMarc75 Vielen Dank!
Wenn immer alles so einfach gehen würde!

[LausiD]

@ok1 sagte in FHEM Adapter:

ich erhalte seit heute Abend folgende Fehlermeldungen im Log, so dass der fhem-Adapter nicht startet.

Welchen Wert hat info.Configurations.allowedInternals?

Hast du die Version von github (16.07.22) ?
Die zweite Instanz geht auf eine andere FHEM Installation?

[Rickman]

Hallo zusammen,

kurze Frage, da ich per Suche nichts gefunden habe.
Ist es möglich per fhem.0.Info.Commands.SendFHEM einen regSet Befehl zu senden, der dann im Gerät auch übernommen wird?
Wenn ich darüber folgenden Befehl sende, steht zwar kurz im Register set_100%, aber wechselt dann wieder auf die in FHEM selbst eingestellten 50%.

set HM_728021_Bright regSet shOnLevel 100 HM_68E334_Sw_01

Es scheint mir, als ob eine Registeränderung über iobroker nicht möglich ist, kann das sein?

Gruß,
Richy

[Rickman]

Niemand eine Idee?

[LausiD]

@rickman
Sollte eigentlich über fhem.0.Info.Commands.SendFHEM laufen....der Wert wird 1:1 an FHEM gesendet.
Funktioniert "set HM_728021_Bright regSet shOnLevel 100 HM_68E334_Sw_01" über die Befehlszeile in FHEM?

Gruß
LausiD

[Rickman]

@lausid said in FHEM Adapter:

shOnLevel 100 HM_68E334_Sw_01

Das hätte ich auch vorher schon mal ausprobieren können...
Mal geht es, meistens aber nicht. Da ist es dann auch egal, ob ich es in der commandline eingebe, oder ob ich es über die Schaltflächen probiere.
Beim ersten Mal funktionierte es in FHEM direkt, daher habe ich das nicht mehr weiter in Betracht gezogen.

Scheit also eher ein FHEM / Geräteproblem zu sein und hat hier wohl nix zu suchen. Sorry!

Gruß,
Richy

[hopsi]

Habe ein Problem, mit fhem.0.send2ioB in einen Datenpunkt bei ioBroker zu schreiben.
Wenn der Datenpunkt als 'Zahl' konfiguriert ist (und das ist er automatisch in diesem Fall), dann kommt bei einem
set fhem.0.send2ioB hmip.0.devices.30142E1B4C00008882440318.channels.1.primaryShadingLevel 0.32
von fhem-Seite her nur der Wert 0 an, die Nachkommastellen werden ignoriert.
ändere ich den Datenpunkt auf 'Zeichenkette', dann wird die 0.32 geschrieben und auch korrekt ausgeführt vom Gerät.
Auf welcher Seite liegt der Fehler? Leider kann ich den Datenpunkt nur bis zum nächsten Einlesen der Geräte umstellen auf 'Zeichenkette', so daß das keine Lösung ist.
Hab unter 0_userdata einen Test-Datenpunkt zum Spielen eingerichtet, der zeigt das gleiche Verhalten: sende ich 0.32, protokolliert ioBroker

stateChange (out): 0_userdata.0.hmip.30142E1B4C00008882440318_primaryShadingLevel | 0 > set 0_userdata.0.hmip.30142E1B4C00008882440318_primaryShadingLevel 0

[hopsi]

@hopsi said in FHEM Adapter:

Wenn der Datenpunkt als 'Zahl' konfiguriert ist (und das ist er automatisch in diesem Fall), dann kommt bei einem
set fhem.0.send2ioB hmip.0.devices.30142E1B4C00008882440318.channels.1.primaryShadingLevel 0.32
von fhem-Seite her nur der Wert 0 an, die Nachkommastellen werden ignoriert.

Habe das Problem gefunden. Nachdem ich wohl keinen Einfluss darauf habe, wie der Datenpunkt angelegt wird, hilft nur ein kleiner Patch, der das Abschneiden der Nachkommastellen verhindert.
Nicht schön, aber läuft.

--- node_modules/iobroker.fhem/main.js.bak      2022-12-10 15:13:24.762686756 +0100
+++ node_modules/iobroker.fhem/main.js  2022-12-10 15:39:42.648445578 +0100
@@ -2558,5 +2558,8 @@
                 } else if (obj && obj.common.write) {
                     let setState = event.substr(parts[0].length + device.length + parts[2].length + 3);
-                    if (obj.common.type === 'number')
+                    //if (obj.common.type === 'number')
+                    if (val.indexOf("primaryShadingLevel") !== -1)
+                        adapter.log.info('[parseEvent] primaryShadingLevel quirks');
+                    if (obj.common.type === 'number' && val.indexOf("primaryShadingLevel") == -1)
                         setState = parseInt(setState);
                     if (obj.common.type === 'boolean')

[D3ltoroxp]

Mir viel auf, das ich über die VIS meine Rollos nicht mehr steuern konnte. Direkt über FHEM geht. Jetzt hab ich mal rein geschaut in die VIS, dort habe ich einen DP Namens

fhem.0.Buero_li.pct

Diesen scheint es nicht mehr zu geben. Unter meinen DP's gibt es den nicht mehr. Hab diesen aber Jahrelang benutzt und auch an der VIS was das Thema Rollos angeht, schon ewig nicht mehr geändert.

Im Log sehe ich auch folgendes...

log ausschnitt.txt

Weiß hier jemand was ? Hat sich was bei FHEM geändert, oder am Adapter ? Hatte bei FHEM auch länger kein Update mehr gemacht, daran sollte es nicht liegen.

[DJMarc75]

@d3ltoroxp sagte in FHEM Adapter:

länger kein Update mehr gemacht, daran sollte es nicht liegen

also bitte... da sollte man als erstes mal anpacken... UPDATES !

[LausiD]

@d3ltoroxp
Welche Version ist der FHEM Adapter?

[D3ltoroxp]

@DJMarc75
Naja irgendwas muss ja an dem Spruch auch dran sein. " Never touch a running System "

Wenn alles stabil läuft wieso Update ?

Hab aber mal alles u2d aber gleiche Probleme, dieser eine DP wird einfach nicht mehr übertragen, existiert einfach nicht in ioB in FHEM schon.

@LausiD Fhem Adapter ist V2.0.2

[DJMarc75]

@d3ltoroxp sagte in FHEM Adapter:

Naja irgendwas muss ja an dem Spruch auch dran sein. " Never touch a running System "

Ein schrecklicher Irrtum...

@d3ltoroxp sagte in FHEM Adapter:

Wenn alles stabil läuft wieso Update ?

Ja genau... wenn alles stabil laufen würde, dann würde man ja kaum einen Beitrag hier im Forum aufmachen !

@d3ltoroxp sagte in FHEM Adapter:

Hab aber mal alles u2d aber gleiche Probleme

Nacherzählungen bringen nix... dass da alles aktuell ist sollte mal die Ausgabe von folgendem sein:

sudo apt update

und das wäre nur mal ein Anfang !

[Thomas Braun]

@d3ltoroxp sagte in FHEM Adapter:

Naja irgendwas muss ja an dem Spruch auch dran sein. " Never touch a running System "

Nein, da ist gar nix dran.
Wenn es keine Probleme gäbe würde kein Update erforderlich sein, dein System ist also schon 'kaputt' und muss angepackt werden.
Den Spruch hörst du auch nie von Administratoren von Systemen sondern immer nur von Leuten die keine Ahnung haben.

[D3ltoroxp]

@djmarc75

Das ist das ioB System.

@Thomas-Braun

Naja, Probleme gibt es ja erst seit neustem, also muss ja irgendwas passiert sein, das dieser DP verschwunden ist und auch nicht mehr erstellt wird. Wie gesagt, in der VIS wird das schon seit Ewigkeit über diesen DP gesteuert, der jetzt bei jedem Rollo fehlt. So kann ich die Rollos auf keine gewünschte Position fahren..

Das System ist jetzt u2d. FHEM wurde aktualisiert, ioB System wurde aktualisiert und die Adapter die ich nutze sind auch u2d.

In der Log sieht man sonst auch nichts. Nur wenn ich eben diesen DP über die VIS befüllen will kommt obiger Logeintrag. Das der FHEM Adapter sonst irgendwelche Probleme hat, steht nichts drin. Am FEHM Adapter wurde ja auch in letzter Zeit doch nichts geändert oder ?

[Thomas Braun]

@d3ltoroxp

Buster ist nicht up-to-date, das ist seit September abgekündigt.

[DJMarc75]

@d3ltoroxp sagte in FHEM Adapter:

Das der FHEM Adapter sonst irgendwelche Probleme hat, steht nichts drin. Am FEHM Adapter wurde ja auch in letzter Zeit doch nichts geändert oder ?

Was sollte da auch drin stehen wenn nur Du da Problemchen hast ?! System auf Stand bringen und dann sehen wir mal weiter !

[D3ltoroxp]

HIER scheint es noch jemand zu geben..

Cannot process object kommt bei mir auch immer.

Ich schau mal wie ich von Buster auf die nächste Version komme und melde mich wieder.

[DJMarc75]

@d3ltoroxp Super dass Du suchst ob Dein Problem auch andere haben Besser wäre zusätzlich die Tipps umzusetzen !
Und dann die "Ergebnisse" posten - damit man weiß ob da dann auch effektiv funktioniert hat

[D3ltoroxp]

So, bin nun auf latest Bullseye (Debian 11) System läuft soweit wieder, aber hat an dem FHEM Problem nichts geändert.

Bin jetzt auf die Version 1.6.3 zurück und sofort waren die DP's wieder da und funktionieren auch. Indem Fall bleib ich erst mal so und melde mich dort mit im Issue. Dann muss sich ja im Update irgendwo ein Fehler eingeschlichen haben.