ESP8266 von Openandhome mit DS18B20

[Sky]

Ich weiß nicht mehr weiter ,
für unseren Pool habe ich mir eine Wlanlösung von Openhome gekauft ,welcher Quelloffen ist .
Auf meinen Fhem habe ich schon MQTT2 mit geflashten Gosund Steckdosen .

Jetzt versuche ich schon seit Stunden den ESP8266 mit Temperaturfühler in Fhem einzubinden ,leider ohne Erfolg

Über die Weboberfläche des ESP ist folgendes eingestellt ( siehe Bild 1 )
In Fhem wird folgendes über "autocreate" erkannt ( siehe Bild 2 )

Ich weiß nicht was ich unter "attrTemplate" einstellen muss ??
Wenn ich  "MQTT2_Client_general_bridge" auswähle und "autocreate" auf 1 , kommt der Sensor ( siehe Bild 4 )

Allerdings kommen keine Readings , was mache ich falsch ??

Danke

[Beta-User]

Gibt es einen Grund, warum du den Thread hier erstellst und nicht im MQTT-Bereich?

Da steht auch in einem angepinnten Thread (bzw. einem Link dort), was an Infos hilfreich wäre...

Ansonsten bitte RAW als Text in Code-Tags, keine screenshots!

Glaskugel sagt: Du mußt ein Messintervall für den Sensor einstellen.

attrTemplate für ESPEasy gibt es noch nicht, die meisten User, die das nutzen, scheinen mit dem ESPEasy-Modul ganz zufrieden zu sein.

[Sky]

Oh , da muss ich mich entschuldigen, kann das jemand nach dort verschieben ?

Ich hatte gedacht das der Beitrag hier richtig ist .

Trotzdem erstmal Danke .

[Nobbynews]

Wieso willst Du unbedingt ein attrTemplate setzen?
Hast Du bei Deinem MQTT2-Server

Code Auswählen Erweitern

attr m2s autocreate complex
gesetzt?
Damit werden mMn die readingList entsprechend gesetzt und auch die Readings angelegt.

[Sky]

Ja das habe ich ..

Code Auswählen Erweitern


defmod m2s MQTT2_SERVER 1883 global
attr m2s autocreate complex
attr m2s room MQTT2

setstate m2s 2020-08-04 14:41:02 RETAIN {"TemperaturSensor/status/LWT":"Connected","sensoren/TemperaturSensor/status/LWT":"Connected","tele/Sonoff_3/LWT":"Online","tele/sonoff_1/LWT":"Offline","tele/sonoff_2/LWT":"Online","tele/sonoff_4/LWT":"Offline"}
setstate m2s 2020-08-04 13:46:20 lastPublish cmnd/sonoff_1/Backlog:StateText1 off;; StateText2 on;; StateText3 toggle;; StateText4 hold;; SetOption26 1;; SaveData 1
setstate m2s 2020-08-04 14:41:02 nrclients 3
setstate m2s 2020-08-04 14:40:52 state Initialized




[Beta-User]

"complex" ist mMn. aus gutem Grund kein default...

Bitte auf simple lassen! Die erweiterten Optionen von json2nameValue() werden dann in der Regel besser über die attrTemplate gesetzt, sonst gibt das unnötigerweise so unübersichtliche Bandwurm-Reading-Namen - wer's mag... (falls ESPEasy überhaupt "JSON spricht" ).

@Nobbynews:
Und woher nimmst du die Weisheit, dass hier überhaupt MQTT2_SERVER im Einsatz ist? Das hier klingt mir eher wie CLIENT ... (U.a., um genau das rauszufinden, habe ich auf den gepinnten Thread verwiesen).

(OK, scheint in der Tat SERVER zu sein. @Sky: Was wolltest du dann mit dem General-Bridge-Template? Das ist nur für CLIENT sinnvoll. Ist die desc nicht eindeutig genug?)


@Sky: Verschieben kannst du selbst (unter dem ersten Thread ist ein Knopf).

[Beta-User]

? "Unterstützende Dienste", wenn es "MQTT" betrifft?


Hast du mal geschaut, ob man den Sensor samt Sendeintervall innerhalb ESPEasy (also auf der Weboberfläche) anlegen kann?

[Sky]

So , jetzt aber im richtigen Board .

? "Unterstützende Dienste", wenn es "MQTT" betrifft?


Hast du mal geschaut, ob man den Sensor samt Sendeintervall innerhalb ESPEasy (also auf der Weboberfläche) anlegen kann?

Die Einstellmöglichkeiten habe ich als Screenshot mal beigefügt .
Ich habe gedacht das ein Template gesetzt werden muss weil der Status "state" auf

Code Auswählen Erweitern

" ??? " bleibt und keine Readings ankommen , in ESPEasy aber schon ( siehe Bild )

Ich bitte um Nachsicht weil dieses Thema für mich neu ist .

Danke

[Beta-User]

ESPEasy ist für mich neu...

Die Sensor-Einstellungen sehen für mich eigentlich soweit ok aus; evtl. könntest du mal eine andere Controller-Variante austesten (k.A., ob OpenHab die richtige Einstellung war oder was anderes besser ist; würde möglichst eher was "generisch MQTT"-mäßiges auswählen).

STATE leitet sich - wenn man sonst nichts einstellt - aus state ab. Kommt da nichts an, bleibt es auf ewig "3?", es sei denn, du nutzt stateFormat und leitest was dahin um. Allerdings sollte irgendwann zumindest eigentlich ein Reading erstellt werden, typischerweise aber eben erst nach Ablauf der 120 Sek., die du eingestellt hattest, und das ganze wird evtl. auch nur sichtbar, wenn man du die Detail-Seite im Browser neu lädst.

[Nobbynews]

"complex" ist mMn. aus gutem Grund kein default...

@Nobbynews:
Und woher nimmst du die Weisheit, dass hier überhaupt MQTT2_SERVER im Einsatz ist? Das hier klingt mir eher wie CLIENT ... (U.a., um genau das rauszufinden, habe ich auf den gepinnten Thread verwiesen).

War ein Schuss in Blaue: device m2S habe ich mal als Abkürzung für MQTT2-Server gedeutet.
Das mit dem complex hatte ich wohl irgendwo gefunden, probiert und lief. Habe ich aber zugegebener Weise nicht weiter hinterfragt.

Ein ESPEasy-Device über MQTT2 angebunden sieht bei mir so aus:

Code Auswählen Erweitern

defmod MQTT2_ESP_01 MQTT2_DEVICE ESPClient_EC_FA_BC_30_4B_09
attr MQTT2_ESP_01 IODev MQTT2_Server
attr MQTT2_ESP_01 icon mqtt_device
attr MQTT2_ESP_01 readingList ESPClient_EC_FA_BC_30_4B_09:ESP_01/BME280/Temperature:.* Temperature\
ESPClient_EC_FA_BC_30_4B_09:ESP_01/BME280/Humidity:.* Humidity\
ESPClient_EC_FA_BC_30_4B_09:ESP_01/BME280/Pressure:.* Pressure\
ESPClient_EC_FA_BC_30_4B_09:ESP_01/status/LWT:.* LWT\
ESPClient_EC_FA_BC_30_4B_09:ESP_01/Status/RSSI:.* RSSI
attr MQTT2_ESP_01 room MQTT2_DEVICE

setstate MQTT2_ESP_01 2020-08-04 17:59:19 Humidity 28.3
setstate MQTT2_ESP_01 2020-08-03 17:01:35 LWT Connected
setstate MQTT2_ESP_01 2020-08-04 17:59:19 Pressure 1013.0
setstate MQTT2_ESP_01 2020-08-04 17:59:19 Temperature 27.4

Die Bezeichnungen in readingList sind in der Tat nicht sehr kurz, bei den readings spielt das aber keine Rolle.
Mit attrTemplate habe ich noch nicht gearbeitet.

[Beta-User]

...vor allem hattest du noch kein Device in der Hand, das JSON sendet, sonst hättest du mit meinen Hinweisen etwas mehr anfangen können ...

Die CID-Angaben (ESPClient_EC_FA_BC_30_4B_09:) kannst du btw. rauswerfen aus readingList.

Weiter würde ich empfehlen, die Readings (v.a. Humidity&Temperature) klein zu schreiben, das entspricht mehr den Gepflogenheiten in FHEM...

Wäre dann eher so:

Code Auswählen Erweitern

attr MQTT2_ESP_01 readingList ESP_01/BME280/Temperature:.* temperature\
ESP_01/BME280/Humidity:.* humidity\
ESP_01/BME280/Pressure:.* pressure\
ESP_01/status/LWT:.* LWT\
ESP_01/Status/RSSI:.* RSSI

[Nobbynews]

Danke für die Hinweise, werde ich mir am Wochenende mal genauer ansehen.
Wenn ich mich aber richtig erinnere, wurden die Readings automatisch so angelegt. Da habe ich händisch nichts geändert.

[Gisbert]

Hallo,

ich hab u.a ESPEasy in der Version mega-20190202 laufen.

In den Controller Settings läuft das Protokoll OpenHab MQTT, und ich nutze die Voreinstellungen bei publish (/%sysname%/%tskname%/%valname%) und subscribe (/%sysname%/#). Es ist immer eine gute Idee unabhängig von Fhem zu prüfen, ob die MQTT-Kommunikation funktioniert. Ich nutze mqttfx auf einem Windowsrechner. Mit dieser Vorgehensweise kann man mögliche Fehler oder falsche Einstellungen eingrenzen. Wenn bei mqttfx nichts ankommt, wird bei Fhem garantiert auch nichts ankommen. %sysname% ist der Unit Name in Main Settings; um Nachrichten zu erhalten, muss man auf /<Unit Name>/+/+ subscribieren (Unit Name ist natürlich zu ersetzen).

Die Vorausetzung ist aber vermutlich ein separater MQTT-Broker, den ich auch in Fhem nutze, old school in Fhem: MQTT-DEVICE anstatt ...2. Vermutlich schreibe ich, da ich nicht weiß, ob es mit dem Fhem-eigenen MQTT-Server auch funktioniert.

Viele​ Grüße​ Gisbert​

[Beta-User]

Wenn der ESP Daten sendet, ist es im Prinzip egal, welcher Server-Typ die empfängt (ausgenommen, es wird MQTT in der Protokoll-Version 5 verwendet; das kann MQTT2_SERVER nicht - ob mosquitto das könnte?).

Das zeigt doch auch das Beispiel von Nobbynews... (btw @Nobbynews: Welchen Controller-Typ hast du eingestellt?) Und auch beim TE wurde ja via autoreate ein Device erstellt, die Frage ist also eigentlich nur, warum das nur mit den Basics klappt (LWT) und nicht auch mit weiteren Readings (die allerdings ggf. einen Browser-Refresh brauchen, bis man sie sieht).

Und da diese firmware kein JSON sendet, ist es - bis auf die viel kompliziertere Ersteinrichtung - auch nicht der große Unterschied, ob man mosquitto+MQTT+MQTT_DEVICE nimmt oder MQTT2_SERVER+MQTT2_DEVICE.

Was autocreate simple/complex bei den MQTT2-IO's anbelangt: Das wirkt sich NUR DANN aus, wenn ein Device JSON verwendet. Ist das - wie hier - nicht der Fall, macht es keinen Unterschied, auch "simple" hätte dieselben Readingnamen erzeugt. Die sind im Prinzip auch ok, aber man _kann_ die eben auf recht einfache Art und Weise auch anders benennen (oder es eben lassen).


EDIT:

Bitte wirf nochmal vor allem das Gerät raus, das als General-Bridge konfiguriert ist. Sonst kann es sein, dass Infos nicht da landen, wo man sie erwarten würde. Eigentlich wäre es das beste, alle MQTT2_DEVICE-Geräte zu löschen, die irgendwas mit diesem ESP zu tun haben. Dann den ESP neu starten.

[Nobbynews]

Die Ursache für die Schreibweise der Readings habe ich gefunden.
Diese sind so im Device von ESPEasy eingetragen.
Controller in ESPEasy ist bei mir ebenfalls der Home Assistent (openHAB) MQTT. Einstellungen eigentlich gem. ESPEasy-Vorgabe.

In den Controller Settings läuft das Protokoll OpenHab MQTT, und ich nutze die Voreinstellungen bei publish (/%sysname%/%tskname%/%valname%) und subscribe (/%sysname%/#).

Dazu noch
Send LWT to broker: enabled
Will Retain: enabled
Clean Session: disabled
Enabled: enabled

[Sky]

Hallo ,
ich habe erst heute wieder Zeit für mein Problem ...

Zuerst habe ich mein Device aus Fhem gelöscht .
Über "autocreat" wurde das Device ,nach einem Neustart, wieder angelegt .
Die Definition sieht jetzt so aus :

Code Auswählen Erweitern


defmod MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor MQTT2_DEVICE ESPClient_84_F3_EB_CC_C1_65:TemperaturSensor
attr MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor IODev m2s
attr MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor icon mqtt_device
attr MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor readingList TemperaturSensor/status/LWT:.* LWT\
TemperaturSensor/DS18b20/Temperature:.* Temperature
attr MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor room MQTT2_DEVICE

setstate MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor 2020-08-05 12:33:51 LWT Connected
setstate MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor 2020-08-05 12:33:52 Temperature 23.50
setstate MQTT2_ESPClient_84_F3_EB_CC_C1_65_TemperaturSensor 2020-08-04 22:21:02 associatedWith MQTT2_ESPClient_84_F3_EB_CC_C1_65



Zumindestens kommt jetzt das reading für die Temperatur .
Allerdings bleibt bei "state" immer noch

Code Auswählen Erweitern

???

Das einzige was ich manuell geändert habe ist das Icon

[Beta-User]

Sieht doch gut aus...

Was STATE (! nicht "state") angeht:

STATE leitet sich - wenn man sonst nichts einstellt - aus state ab. Kommt da nichts an, bleibt es auf ewig "3?", es sei denn, du nutzt stateFormat und leitest was dahin um.

Du kannst statt stateFormat auch eines der Readings direkt mit readingList nach "state" umleiten, wenn du das anders haben willst:

Code Auswählen Erweitern

TemperaturSensor/status/LWT:.* state
@Nobbynews:
Wie du siehst, kommt nur die _Vorbelegung_ der Readingnamen für autocreate aus dem, was man in ESPEasy/der firmware einträgt; in FHEM kann man das praktisch _beliebig_ ändern: Sendet das Gerät Klartext, geht das so wie in meinen Beispielen hier, wird die Payload in JSON verpackt, braucht man dazu - genau! - complex bzw. die um $JSONMAP erweiterte Form von json2nameValue()... Die kann man bei den Topics, bei denen man das wirklich braucht dann aber auch händisch eintragen, denn in der Regel muß man sich dann sowieso umfassender Gedanken machen, was wohin soll .
Hoffe, das Bild wird nun etwas klarer?

[Sky]

Ein großes Danke für Eure Hilfe beim lösen meines Problems .

[Nobbynews]

@Nobbynews:
Wie du siehst, kommt nur die _Vorbelegung_ der Readingnamen für autocreate aus dem, was man in ESPEasy/der firmware einträgt; in FHEM kann man das praktisch _beliebig_ ändern: Sendet das Gerät Klartext, geht das so wie in meinen Beispielen hier, wird die Payload in JSON verpackt, braucht man dazu - genau! - complex bzw. die um $JSONMAP erweiterte Form von json2nameValue()... Die kann man bei den Topics, bei denen man das wirklich braucht dann aber auch händisch eintragen, denn in der Regel muß man sich dann sowieso umfassender Gedanken machen, was wohin soll .
Hoffe, das Bild wird nun etwas klarer?

Das werde ich mir auf jeden Fall genauer ansehen. Bisher lief es halt und damit war ich zufrieden. Heute Morgen habe ich mal testweise auf die Schnelle einen meiner Shellyplug (nutze aktuell nur die Messfunktion) entsprechend umgestellt.
Und der sollte doch JSON liefern.

[Beta-User]

Das werde ich mir auf jeden Fall genauer ansehen. Bisher lief es halt und damit war ich zufrieden. Heute Morgen habe ich mal testweise auf die Schnelle einen meiner Shellyplug (nutze aktuell nur die Messfunktion) entsprechend umgestellt.
Und der sollte doch JSON liefern.

Jein. Insbesondere die Energie-Werte kommen als Klartext, nur manche andere Infos sind JSON-verpackt, und für die nutzen jedenfalls "meine" attrTemplate dann aber auch "nur" json2nameValue-"simple" . Details siehe ab hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L1797

Kurz: Wenn du keinen ebus oder was vergleichbar komplexes nutzt, macht "complex" keinen Sinn... (deswegen heißt es auch "complex", btw. ). Aber klar: das mit "complex" zu machen funktioniert _auch_, man macht sich halt nur in der Regel das Leben schwerer als es sein müßte . (Und genau deswegen ist "simple" auch der default).

Und eine "Umstellung" wirkt nur im Rahmen von MQTT2_DEVICE-autocreate. Bei bekannten Geräten/Topics wirkt sich das dementsprechend nicht aus, weil dann logischerweise auch autocreate gar nicht greift .

[Nobbynews]

Und eine "Umstellung" wirkt nur im Rahmen von MQTT2_DEVICE-autocreate. Bei bekannten Geräten/Topics wirkt sich das dementsprechend nicht aus, weil dann logischerweise auch autocreate gar nicht greift .

Ahhh, soetwas hatte ich mir nach der Umstellung schon gedacht.
Aber löschen und neu anlegen ist ja kein Problem.
Das attr complex habe ich schon geändert. Ebus nutze ich nicht.
Wieder etwas dazugelernt.
Danke.