Moin,
ich habe eine Frage zu einem ESP8266-Device mit einem Relais und ESPEasy. Es wurde im ESP ein Switch auf dem (Relais)-GPIO angelegt, um den Schaltzustand anzeigen zu können. In fhem existiert das Gerät, es lässt sich alles schalten.
Wenn nun fhem neu gestartet wird, dann steht das Reading state auf "opened". Das Reading, welches den Status des Switches anzeigen soll, steht auf "gpio". Es wird also nicht abgefragt, welchen Zustand die enstpr. GPIO haben. Erst nach einmaligem Schalten stimmen wieder alle Anzeigen.
Dies bereitet mir Probleme, da ich die Schaltzustände als Bedingungen in DOIF verwende.
Was muss ich tun, damit auch nach fhem Neustart die aktuellen Zustände des ESP abgefragt werden?
Danke
Michael
Zitat
Wenn nun fhem neu gestartet wird, dann steht das Reading state auf "opened".
Works as designed.
Zitat
Das Reading, welches den Status des Switches anzeigen soll, steht auf "gpio".
Könnte mit eventMap zusammenhängen. Zeig mal ein list vom betroffenen Device.
ZitatWorks as designed.
Wäre ja auch schlecht wenn nicht. But maybe the design has room for improvement.
Hier das Listig nach Neustart fhem:
Internals:
DEF 192.168.0.230 80 ESPEasyBridge Skynet_Dualswitch_1_Relais2
HOST 192.168.0.230
IDENT Skynet_Dualswitch_1_Relais2
INTERVAL 300
IODev ESPEasyBridge
NAME AU_SW_Laterne
NOTIFYDEV global
NR 357
NTFY_ORDER 50-AU_SW_Laterne
PORT 80
STATE gpio
SUBTYPE device
TYPE ESPEasy
VERSION 0.82
Readings:
2017-02-22 17:06:55 state opened
2017-02-22 15:18:39 status gpio
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 22.02.2017 17:11:59
Received:
Attributes:
IODev ESPEasyBridge
Interval 300
comment Relais 2 = GPIO 14
eventMap /gpio 14 on:on/gpio 14 off:off
group ESPEasy Device
presenceCheck 0
readingSwitchText 1
room 3.7_Aussen
setState 3
stateFormat status
webCmd on:off Und so sind die Readings korrekt da, nachdem ich auf "on" und dann "off" geklickt habe:
Internals:
DEF 192.168.0.230 80 ESPEasyBridge Skynet_Dualswitch_1_Relais2
ESPEasyBridge_MSGCNT 2
ESPEasyBridge_TIME 2017-02-22 17:09:58
ESP_BUILD 147
ESP_SLEEP 0
ESP_UNIT 2
HOST 192.168.0.230
IDENT Skynet_Dualswitch_1_Relais2
INTERVAL 300
IODev ESPEasyBridge
LASTInputDev ESPEasyBridge
MSGCNT 2
NAME AU_SW_Laterne
NOTIFYDEV global
NR 357
NTFY_ORDER 50-AU_SW_Laterne
PORT 80
STATE off
SUBTYPE device
TYPE ESPEasy
VERSION 0.82
Readings:
2017-02-22 17:09:58 state sta: off
2017-02-22 17:09:58 status off
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 304
TRIGGERTIME 22.02.2017 17:11:59
Received:
status 1487779798.82189
Attributes:
IODev ESPEasyBridge
Interval 300
comment Relais 2 = GPIO 14
eventMap /gpio 14 on:on/gpio 14 off:off
group ESPEasy Device
presenceCheck 0
readingSwitchText 1
room 3.7_Aussen
setState 3
stateFormat status
webCmd on:off Gruß
Michael
Lösch mal das eventMap Attribut, config speichern und neu FHEM neustarten. Ändert sich das Verhalten bzgl. "gpio" im Reading dann?
Ja, jetzt passt die Anzeige. Das Reading status vom ESP wird zwar nicht neu eingelesen beim Neustart (der Zeitstempel zeigt die letzte Änderungszeit an), aber auch nicht "falsch" mit gpio überschrieben.
Dafür kann ich jetzt natürlich über die on/off-Buttons nichts mehr klickbar schalten.
Wenn die Readings ohne eventMap Attribut korrekt sind, dann würde ich auf ein Fehlverhalten von eventMap tippen. Frag mal den zuständigen Maintainer.
Um den aktuellen Status nach einem Neustart zu erhalten kannst auf global:INITIALIZED triggern und einen statusrequest in Verbindung mit dem pollGPIOs Attribut ausführen oder den ESP aktiv den Status alle x Sekunden senden lassen.
Zitat von: dev0 am 22 Februar 2017, 18:47:41
Um den aktuellen Status nach einem Neustart zu erhalten kannst auf global:INITIALIZED triggern und einen statusrequest in Verbindung mit dem pollGPIOs Attribut ausführen oder den ESP aktiv den Status alle x Sekunden senden lassen.
Die Lösung scheint nur teilweise eine "vernünftige" zu sein. Wenn ich das richtig sehe, fragt fhem mit Setzen von pollGPIOs im Intervall des Attributs Intervall nun regelmäßig die GPIO ab. Das will ich aber eigentlich nicht. Ein größeres Problem ist aber, dass pollGPIOs neue Readings anlegt.
Normalerweise existiert in fhem im Device eines Switches ein Reading mit dem Namen, den man in ESPEasy unter "Values" vergeben hat (bei mir status). Sobald ich manuell oder per Kommando schalte, ändert sich das ESP-Value-Reading. Fragt nun pollGPIOs die Pins ab, dann steht der Status im Reading "GPIO<Nummer des GPIO>". Dummerweise ändern sich diese Readings aber nicht beim Schalten des Devices, dann ändert sich nämlich das ESP-Value-Reading. Somit kann ich kein stateFormat formulieren, wenn der Zustand der Pins in zwei Readings auftauchen kann.
Beim Neustart steht in meinem Reading "status" leider nicht on/off, sondern "gpio", deswegen schreibt stateFormat das bei mir so in STATE und zack... passt die Anzeige und vor allem meine DOIF nicht mehr.
relevante Teile des Listings nach Neustart:
Internals:
Internals:
...
Readings:
2017-02-23 08:18:40 GPIO14 off
2017-02-23 08:18:40 GPIO14_mode output
2017-02-23 08:18:40 state GPI: off
2017-02-23 08:10:08 status gpio
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 305
TRIGGERTIME 23.02.2017 08:23:45
Received:
GPIO14 1487834320.85035
GPIO14_mode 1487834320.8487
Attributes:
IODev ESPEasyBridge
Interval 300
comment Relais 2 = GPIO 14
eventMap /gpio 14 on:on/gpio 14 off:off
group ESPEasy Device
pollGPIOs 14
presenceCheck 0
readingSwitchText 1
room 3.7_Aussen
setState 3
stateFormat status
webCmd on:off Und so, nachdem ich manuell geschaltet habe, nun sind beide Readings desselben Pins asynchron:
Internals:
Internals:
...
Readings:
2017-02-23 08:23:45 GPIO14 off
2017-02-23 08:23:45 GPIO14_mode output
2017-02-23 08:25:40 state GPI: off sta: on
2017-02-23 08:25:40 status on
Helper:
Intat:
1:
FN ESPEasy_statusRequest
INTERVAL 300
TRIGGERTIME 23.02.2017 08:28:45
Received:
GPIO14 1487834625.08844
GPIO14_mode 1487834625.08662
status 1487834740.53256
Attributes:
IODev ESPEasyBridge
Interval 300
comment Relais 2 = GPIO 14
eventMap /gpio 14 on:on/gpio 14 off:off
group ESPEasy Device
pollGPIOs 14
presenceCheck 0
readingSwitchText 1
room 3.7_Aussen
setState 3
stateFormat status
webCmd on:off Irgendwie müssten die Readings GPIO<> und ESP-Value-Reading übereinander gebracht werden. Es ist klar, dass das Modul nicht weiß, welches Value-Reading im Falle eines Switches zu welchem GPIO gehört, aber vielleicht kann man das als Attribut setzen? Dann sollten durch pollGPIOs keine neuen Readings GPIO<> erzeugt werden, sondern ein direktes Mapping auf die ESP-Value-Readings erfolgen.
Ggf. wäre es dann auch eine Idee, dass erste Abfragen nach Initialize ganze als Attribut zu definieren, um sich das Triggern und DOIF oder at zu sparen? So etwas wie "pollGPIOsOnInitialize" in Verbindung mit dem Attribut "pollGPIOs" und "Intervall=0"? Dann bliebe die Funktionalität innerhalb des Moduls und man benötigt keine zusätzlichen DOIF.
Gruß
Michael
Zitat von: MichaelO am 23 Februar 2017, 08:33:05
ann steht der Status im Reading "GPIO<Nummer des GPIO>".
Der Ausdruck GPIO läßt sich über ein Attribut einstellen. Sonst pass auf ESP Seiten den Value Name an, dass es synchron wird.
Zitat
Beim Neustart steht in meinem Reading "status" leider nicht on/off, sondern "gpio"
Das hatten wird doch schon: das ist ein Seiteneffekt der durch eventMap hevorgerufen wird. Ob das an einer falschen eventMap Syntax oder ein Fehlverhalten von eventMap ist, weiß ich nicht, es läßt sich aber mit einem Dummy nachstellen. Es ist also kein Problem des ESPEasy Moduls und ich bin raus.
define d dummy
attr d eventMap /gpio 14 on:on/gpio 14 off:off/
list d
Internals:
.eventMapCmd on:noArg off:noArg
CFGFN
NAME d
NR 24140
STATE ???
TYPE dummy
Attributes:
eventMap /gpio 14 on:on/gpio 14 off:off/
set d on
list d
Internals:
.eventMapCmd on:noArg off:noArg
CFGFN
NAME d
NR 24140
STATE on
TYPE dummy
Readings:
2017-02-23 09:32:48 state gpio 14 on
Attributes:
eventMap /gpio 14 on:on/gpio 14 off:off/
save
Wrote configuration to /opt/fhem-dev/fhem-dev.cfg
shutdown restart
list d
Internals:
.eventMapCmd on:noArg off:noArg
NAME d
NR 169
STATE on
TYPE dummy
Readings:
2017-02-23 09:32:48 state gpio
Attributes:
eventMap /gpio 14 on:on/gpio 14 off:off/
Zitat
Ggf. wäre es dann auch eine Idee, dass erste Abfragen nach Initialize ganze als Attribut zu definieren, um sich das Triggern und DOIF oder at zu sparen? So etwas wie "pollGPIOsOnInitialize" in Verbindung mit dem Attribut "pollGPIOs" und "Intervall=0"? Dann bliebe die Funktionalität innerhalb des Moduls und man benötigt keine zusätzlichen DOIF.
Am liebsten würde ich das ganze Pollen aus dem Modul rausschmeißen, da das nur ein Workaround für Unzulänglichkeiten von ESPEasy bzw. von ESPEasy Plugins ist. Es gibt zZ keine Möglichkeit einen statusRequest anzustoßen, der die aktuellen Werte über den offiziellen Weg schickt. Ich werte beim pollen die JSON Response aus, diese enthält aber nicht die vollständigen Informationen... Der korrekte Weg wäre das in ESPEasy zu implementieren. Hast Du Lust dazu?
Fazit: Das Einfachste ist, wenn Du vom ESP die Werte alle xx Sekunden senden läßt. Der falsche Wert (gpio) hat nichts mit dem ESPEasy Modul zu tun, wende Dich dazu an den Maintainer.
Sorry, dass ich den Threat eröffnet habe. Ich dachte, man könne ggf. Verbesserungen am Modul anstoßen, die auch anderen Nutzern das Leben erleichtert.
ZitatAm liebsten würde ich das ganze Pollen aus dem Modul rausschmeißen, da das nur ein Workaround für Unzulänglichkeiten von ESPEasy bzw. von ESPEasy Plugins ist. Es gibt zZ keine Möglichkeit einen statusRequest anzustoßen, der die aktuellen Werte über den offiziellen Weg schickt. Ich werte beim pollen die JSON Response aus, diese enthält aber nicht die vollständigen Informationen... Der korrekte Weg wäre das in ESPEasy zu implementieren. Hast Du Lust dazu?
Wenn ich das mal eben könnte, dann würde ich es implementieren. Nun weiß ich, dass es so nicht geht und werde einen Weg suchen.
Trotzdem danke für die Mühe bislang.
Gruß
Michael
Zitat von: MichaelO am 23 Februar 2017, 10:50:33
Sorry, dass ich den Threat eröffnet habe.
Kein Problem. Nur gut, dass ich trotzdem helfen konnte ohne dass Du es bemerkt hast.
Zitat von: dev0 am 22 Februar 2017, 18:47:41
Um den aktuellen Status nach einem Neustart zu erhalten kannst auf global:INITIALIZED triggern und einen statusrequest.......
Ich würde auch gerne alle ESP-Devices nach einem FHEM-Neustart einmal anfragen....
Hast du ein Beispiel für mich, wie man das Ereignis global:INITIALIZED abfragt?
Gruß
Pf@nne
ZitatHast du ein Beispiel für mich, wie man das Ereignis global:INITIALIZED abfragt?
So kann es gehen...
DOIF (["^global$:MODIFIED $SELF$"])
(mache Dinge nach Initialize)Gruß
Michael
Moin,
so richtig will das noch nicht....
define fhemINITIALIZED DOIF (["^global$:MODIFIED $SELF$"]) (fhem("set ade write HelloWorld"))
attr fhemINITIALIZED room _System
Das set ist ein MQTT-publish, vieleicht ist FHEM zu diesem Zeitpunkt noch garnicht mit dem Broker verbunden?
Das set ansich funktioniert....
define INIT dummy
attr INIT room _System
attr INIT setList on off
attr INIT webCmd on:off
define nf_INIT notify INIT { \
if($EVENT eq "on") {\
fhem("set ade write HelloWorld");;\
}\
}
attr nf_INIT room _System
Deine Vermutung könnte stimmen. Dann trigger doch auf die Verbindung mit dem Broker... gibt es da irgendein Event? Ich hab keinen Broker laufen.
Darüber hinaus kannst Du das Kommando set... direkt schreiben, ohne 'fhem':
(set ade write HelloWorld)
Was sagt denn das Logfile an der Stelle?
Der MQTT-Broker meldet die Verbinding zurück:
2017-02-23 17:59:52 MQTT MQTT_Broker connection: active
Aber es funktioniert auch mit einem einfachen Dummy nicht...
define fhemINITIALIZED DOIF (["^global$:MODIFIED $SELF$"]) (set INIT on)
attr fhemINITIALIZED room _System
define INIT dummy
attr INIT room _System
attr INIT setList on off
attr INIT webCmd on:off
Hier sollte doch der Dummy INIT nach dem Neustart auf on stehen?
@Pf@nne: Du mußt auf global:INITIALIZED triggern, nicht auf MODIFIED:
define nf notify global:INITIALIZED {Log 1, 'Hello Pf@nne'}
versuche mal
define fhemINITIALIZED DOIF ([MQTT:"active"]) (set INIT on)
Das sollte triggern, sobald das Gerät MQTT ein Event auslöst, in dem "active" vorkommt.
Moin,
define fhemINITIALIZED notify global:INITIALIZED { \
fhem("set ADE_Relay getStatus Relay");;\
}
attr fhemINITIALIZED room _System
Läuft einwandfrei.... Danke euch!
Die Verbinding zum MQTT-Broker ist zu diesem Zeitpunkt auch schon da!
Nur der "upzudatende" MQTT_DEVICE selber ist zu diesem Zeitpunkt noch nicht bereit.
Das Topic mit dem aktuellen state vom ESP8266-Device kommt zu schnell rein.
Ich habe jetzt auf der Device-Seite das publish des states um 2 Sekunden verzögert.
Das ist natürlich nicht ganz sauber, habt ihr noch eine Idee wie man das Problem auf der FHEM-Seite "umschiffen" könnte?
Ich könnte sonst auch die FHEM-Anfrage verzögert senden, mit sleep steht ja aber auch alles, oder?
Gruß
Pf@nne
Ich empfinde das nicht als unsauber und würde es so lassen. Alternativ mußt du halt prüfen ob das Device bereit ist, wenn nicht dann alle x Sekunden wieder prüfen...
Dann bleibt es so....Danke!