ESP8266 von Openandhome mit DS18B20

Begonnen von Sky, 04 August 2020, 14:45:44

Vorheriges Thema - Nächstes Thema

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 :


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 ???

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

Beta-User

Sieht doch gut aus... :)

Was STATE (! nicht "state") angeht:
Zitat von: Beta-User am 04 August 2020, 16:10:33
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:
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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sky

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


;)

Nobbynews

#18
Zitat von: Beta-User am 05 August 2020, 12:55:39

@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

Zitat von: Nobbynews am 05 August 2020, 13:29:51
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" 8) . 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 ;D . (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 ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Nobbynews

#20
Zitat von: Beta-User am 05 August 2020, 13:47:12
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.