neues Modul DOIF

[Damian]

Meinst du mit Doku den Post 1? oder hab ich was verschlafen?


Ansonsten verstanden, danke.

ja, zu cmd_3 meinte ich diesen Satz aus der Doku:

Auch wenn kein DOELSE-Fall angegeben wird, wird der entsprechende Status gesetzt, falls keiner der definierten DO-Fälle zutrifft.

Gruß

Damian

[Damian]

Sorry - wieder der Lästige

Jedesmal wenn ich händische Änderungen an der fhem.cfg (natürlich an anderer Stelle) vornehme, sind die DOIF-Defines in Fehm verschwunden. Fehlermeldung zB nach einem rereadcfg:

"0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
DI_markise DOIF: unknown reading: netatmo_ter:temperature
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first "

Auch nach einem shutdown+restart oder einem reboot meines Raspi sind die Defines verschwunden.

Hierzu steht in der Doku, Zitat:

Die Definition eines DOIF-Moduls sollte über die Weboberfläche vorgenommen werden und nicht manuell in der fhem.cfg gemacht werden, insbesondere, weil zum Zeitpunkt der Definition die Existenz der angegebenen Devices geprüft wird.

Gruß

Damian

[kkoeniger]

Ich definiere ja die DOIF-Defines oder -attr nicht in der Config. Die nehme ich ja auf der Weboberfläche vor. Änderungen mache ich an anderer Stelle, anderen attr anderer defines.

Das würde ja bedeuten, dass die fhem.cfg eigentlich vollständig gesperrt werden muss, damit dort bei Nutzung des 98_DOIF.pm niemand mehr etwas ändert, wenn ich auch an anderen defines/attr nichts mehr ändern darf.

Auch beim Zurückkopieren einer (mir DOIF-) funktionierenden fhem.cfg-Sicherung samt folgendem rereadcfg oder bei einem reboot des Raspi kommen die Fehlermeldungen.

Was mache ich falsch?

[der-Lolo]

Was mache ich falsch?

Du bearbeitest die fhem.cfg

[kkoeniger]

Scheint aber nicht unbedingt etwas damit zu tun haben, wenn die Fehler auch nach einem Reboot auftauchen.

[Damian]

Scheint aber nicht unbedingt etwas damit zu tun haben, wenn die Fehler auch nach einem Reboot auftauchen.

Wenn du in deiner fhem.cfg dein DOIF Modul an der falschen Stelle einfügst, nämlich bevor die Devices definiert werden, dann wirst du das Problem immer haben.

Wenn du es über Weboberfläche machst, dann weißt du während der Definition, ob du syntaktisch richtig liegst und die Devices bereits definiert sind. Das Modul wird dann anschließend am Ende der cfg-Datei angefügt. Anschließend config save und dein System funktioniert auch nach dem Reboot

Gruß

Damian

[kkoeniger]

Naja, an und für sich fügte ich in die Config bisher nichts falsch ein, das tolle Fhem läuft bei mir seit 4 Monaten auf 2 Raspis mit etwa entities:100 device:30 ... Normalerweise kann ich mit INIs, REGs und CFGs umgehen. Aber was solls ...

Retry von heute:

• Hardreset Raspi (Strom aus)
• define in die Befehlszeile von Fhem eingefügt
• attr definiert
• Save config angeklickt, Bestätigungemeldung erschien, fhem.cfg nichts gemacht
• Fhem shutdown restart
• warten bis Fhem wieder läuft, Fhem mit room aufgerufen
• keine Fehlermeldung, aber vom define ist absolut nichts zu sehen ! (nicht im Room, nicht in der config)
• fhem shutdown restart
• nur das define in die Befehlszeile von Fhem eingefügt, keine attr definiert
• Save config angeklickt, Bestätigungemeldung erschien, fhem.cfg nichts gemacht, das DOIF ist im room unsorted zu sehen
• Fhem shutdown restart
• warten bis Fhem wieder läuft
• diesmal nicht direkt einen room aufgerufen, sondern url:port/fhem?
• Errormeldung:Error messages while initializing FHEM:
  configfile: 0
  DI_qion DOIF: unknown reading: strommess:energy
  statefile: Please define DI_qion first
  Please define DI_qion first
• das DOIF ist im room unsorted NICHT zu sehen
• die config nicht in Fhem, sondern über einen FTP angschaut (dort auch nicht gespeichert), das define steht noch ganz unten
• Save config angeklickt, Bestätigungemeldung erschien
• die config nicht in Fhem, sondern über einen FTP angschaut. Das define, vor 5 sec noch ganz untenstehend ist nun weg.

Hier noch die fheminfo dieses Raspi:
  Release  : 5.5
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : arm-linux-gnueabihf-thread-multi-64int
  Perl     : v5.14.2
  uniqueID : xxxxx
  upTime   : 00:15:14
Auch nach einem neuerlichen Eingeben des define (im room unsorted zu sehen) mit anschließendem Save config in der fhem-Befehlszeile ist das Modul DOIF nicht aufgelistet:
...
  CUL             : 1
  CUL_HM          : 86
  Dashboard       : 1
  EGPM            : 4
  EGPM2LAN        : 1
  ENIGMA2         : 1
...

Gleiches übrigens nach einem reload 98_DOIF.pm (und ja, fhem ist owner des Moduls).

Konklusio für mich: auch wenn ich die fhem.cfg nicht berühre, erhalte ich Fehlermeldungen und das define verschwindet.

[Damian]

Auch nach einem neuerlichen Eingeben des define (im room unsorted zu sehen) mit anschließendem Save config in der fhem-Befehlszeile ist das Modul DOIF nicht aufgelistet:

Gleiches übrigens nach einem reload 98_DOIF.pm (und ja, fhem ist owner des Moduls).

Konklusio für mich: auch wenn ich die fhem.cfg nicht berühre, erhalte ich Fehlermeldungen und das define verschwindet.

Ok. Dann scheint es ein Problem zu sein, das ich so bei mir noch nicht hatte.

Ich gehe davon aus, dass FHEM die fhem.cfg sequentiell abarbeitet. Wenn also zuerst ein Device in der config vorkommen und dann das definierte DOIF-Modul, dass dann die Definition klappt. Ich arbeite seit über einem Jahr  mit zig THRESHOLD Modulen, die ebenfalls die Existenz von Devices bei der Definition überprüfen und hatte dieses Verhalten noch nie gehabt - habe allerdings die fhem.cfg, bis auf die ip-Anpassung ganz am Anfang, manuell nie angepackt. Wenn es also ein grundsätzliches Problem wäre, dann müsste es beim THRESHOLD-Modul, dass von vielen benutzt wird, schon Beschwerden geben.

Die erste Frage ist. Nachdem du dein DOIF-Modul über die Kommadozeile erfolgreich definiert hast und config save gemacht hast. Stimmt die Reihenfolge in der fhem.cfg (zuerst Device-Definitionen, dann DOIF-Definition)?

Wenn das nicht der Fall ist, dann ist klar, dass nach dem Reboot es nicht klappt. Dann würde ich den DOIF-Eintrag manuell in der fhem.cfg nach hinten verschieben (hinter die Devices) und neu booten.

Ich kenne nicht die programmierten FHEM-Abläufe bei der Auswertung der fhem.cfg, vielleicht kann der Rudi etwas dazu sagen.

Gruß

Damian

[kkoeniger]

Danke, dass Du Dich meiner Sache so annimmst!

Direkt aus der fhem.cfg, dort steht es ganz unten am Schluss (ich habe seit gestern werder etwas händisch noch per FHEM-web geändert), per FTP rauskopiert:

Code Auswählen Erweitern

### 25.06.2014 ##############
define DI_qion DOIF ([kkathome] eq "zu Hause" and [strommess:energy] > 300)(set WZLeiste_Socket_3 on) DOELSEIF ([kkathome] eq "ausser Haus")(set WZLeiste_Socket_3 off) DOELSEIF ([strommess:energy] <= 300)(set WZLeiste_Socket_3 off) DOELSE (set WZLeiste_Socket_3 off)
attr DI_qion alias Qi-Lader auto
attr DI_qion cmdState zu Hause -> ein|weg -> aus|wenig PV -> aus|off (warum?)
attr DI_qion do always
attr DI_qion group Stecker
attr DI_qion icon audio_repeat
attr DI_qion room WZ
attr DI_qion wait 60:60:60:60

Soweit ich das beurteilen kann, scheint es mir ok zu sein. Ich denke daher, dass Dein Modul (wie ich nicht anders erwartete) alles korrekt macht. Ich habe daher weiter geforscht (wobei das define und die attr jetzt immer in der fhem.cfg stehen blieben, aber nichts auf der FHEM-Oberfläche zu sehen ist - vllt weil ich kein save mehr machte):

ein rereadcfg liefert:
"0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first"

ein reload 98_DOIF.pm liefert keinen Fehler

nach shutdown restart:

Error messages while initializing FHEM:
configfile: 0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first"

So wie ich das jetzt interpretiere, findet FHEM das Modul 98_DOIF.pm einfach nicht, obwohl fhem der owner ist und das Oktal 666. Das Modul selbst hatte ich schon wiederholt ins directory kopiert.

Ich überlege jetzt weiter, wie ich das beheben kann.

[Damian]

nach shutdown restart:

Error messages while initializing FHEM:
configfile: 0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first"

So wie ich das jetzt interpretiere, findet FHEM das Modul 98_DOIF.pm einfach nicht, obwohl fhem der owner ist und das Oktal 666. Das Modul selbst hatte ich schon wiederholt ins directory kopiert.

Ich überlege jetzt weiter, wie ich das beheben kann.

Also diese Fehlermeldung kommt ja von DOIF, d. h. DOIF wurde korrekt geladen, findet aber nicht dein strommess-Device und daraus folgend wird DI_qion nicht definiert.

Die Frage muss hier lauten: Warum ist strommess noch nicht definiert an dieser Stelle?

Gruß

Damian

[Damian]

Ich sehe gerade. Die Fehlermeldung sagt, dass er das Reading nicht findet und nicht das Device. Das könnte tatsächlich sein, dass zu diesem Zeitpunkt noch kein reading "energy" tatsächlich existiert und erst später vom Device "strommess" erstellt wird. Das würde das Fehlverhalten erklären. Das würde bedeuten, dass ich die Überprüfung auf Readings ändern müsste, also höchsten als Warning mit logeintrag ohne Fehlercode, so dass die Definition des DOIF-Moduls klappt. Die Überprüfung auf Devices lasse ich dagegen wie sie ist.

Gruß

Damian

[kkoeniger]

Ja

"energy" ist ein berechnetes Reading von 3 devices:

Code Auswählen Erweitern

attr strommess userReadings energy {ReadingsVal("Solar","AC.Power.Fast",0) - ReadingsVal("pvliefer","electricityPower",0) + ReadingsVal("strombezug","electricityPower",0);;;;}, energyToday {ReadingsVal("Solar","Daily.Energy",0) - ReadingsVal("pvliefer","electricityConsumedToday_kWh",0) + ReadingsVal("strombezug","electricityConsumedToday_kWh",0);;;;}

"Solar" ist mein Kostal-Wechselrichter.
"pvliefer" und "strombezug" sind je ein YouLess LS110.
Alle 3 Geräte werden per IP ausgelesen und es kann durchaus sein, dass "energy" beim Start von FHEM oder einem rereadcfg noch nicht befüllt ist.

Edit: getriggert wird "strommess" über ein notify alle 10 sec, d.h. das reading steht erst danach zur Verfügung.

[rudolfkoenig]

Ich kenne nicht die programmierten FHEM-Abläufe bei der Auswertung der fhem.cfg...

Waere aber leicht nachzuschauen.
FHEM liest beim Start bzw. restart erst fhem.cfg und danach fhem.state mit dem include Befehl rein, d.h. die Zeilen in diesen Dateien werden so ausgewertet, als ob man diese eins nach dem anderen eingetippt haette.

[Damian]

Ich habe in der Doku (erster Post hier) ein Beispiel zu Beschattungssteuerung aufgenommen:

Code Auswählen Erweitern

define DI_Rolladen DOIF ([Sensor:temperature] > 26 and $hms gt "11:00" and $hms lt sunset_abs()) (set Rollo runter) DOELSE (set Rollo hoch)
attr DI_Rolladen wait 900:900

An diesem Beispiel kann man erkennen, dass man in der Bedingung auch beliebige Perlfunktionen, hier sunset_abs(), nutzen kann. So kann man insb. auch selbsterstelle Funktionen in DOIF  für Abfragen nutzen.

Nun könnte jemand auf den Gedanken kommen, dass man so etwas genauso gut mit notify und if machen könnte. Dem sei gesagt: Beim notify müsste man sich selbst um die Zustandsbehandlung kümmern, ansonsten wird jedesmal der Rolladen geschaltet, wenn der Sensor einen Wert liefert.

Gruß

Damian

[rudolfkoenig]

Oder man verwendet die FILTER Funktion der devspec