ShellyFlood

[olwaldi]

Was verhindert die Benutzung von userReading?

LG

pah

Nix.

Mir gehts nur ums "Prinzipielle". Irgendwieso steht da ein Reading mit Namen 1 bzw. -, und das müßte doch irgendwo in fhem korrigierbar sein. Wenn ich ein userReading über

Code: [Auswählen]

ReadingsVal("MQTT2_shellyflood_B08543", "1", "hmm")ist das m. E. eine Art workaround, der natürlich auch funktioniert.

Wie schon geschrieben, meine "Probleme" sind rein kosmetischer Art. Das fhem-Dashboard nutze ich momentan nur selten (wenn irgendein Fehler auftreten sollte).

Übrigens, meine Batterie im shellyflood ist immer noch bei 100%, sehr zufriedenstellend!! Allerdings fehlt hin und wieder die tägliche Meldung, da mein WLAN-Empfang dort eher schlecht ist. Das sollte ab heute nach Integration eines zusätzlichen WLAN-Repeaters im Keller besser werden.


Grüßle, Michael

[TomLee]

Code: [Auswählen]

und das müßte doch irgendwo in fhem korrigierbar sein
Geht, siehe https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Die_JSON-Daten_vor_dem_auspacken_manipulieren

Edit: Falsch, nicht nachgedacht, schau dir das Attribut  jsonMap an.

Edit2: war mir nicht mehr in Erinnerung, klappt es denn nicht wie in #37 vorgeschlagen ? Du hättest noch die readingList anpassen müssen wie vorgeschlagen und in #41 nochmal darauf hingewiesen wurde.

[olwaldi]

Ich habe gerade fhem komplett aktualisiert. Damit gabs auch ein aktualisiertes template (mit jsonmap). Das habe ich erneut zugeordnet. Morgen weiß ich dann mehr (shellyflood geht ja nur 1x täglich online).

Wie ich aber schon in einem meiner Beiträge weiter oben geschrieben habe, scheint das MQTT topic laut Herstellerdoku anders zu heißen, nämlich

Code: [Auswählen]

shellies/MQTT2_shellyflood_B08543/status/act_reasonssprich' status anstelle von sensor. Das teste ich dann ggf. morgen...

Wie stehts denn um das Thema Firmware-update? Klappt das nur, wenn der shellyflood im Moment des set-Kommandos x_update online ist oder wird ein Flag in fhem gesetzt, so daß das Firmware-update bei der nächsten online-Meldung automatisch ausgeführt wird?


Grüßle, Michael

[olwaldi]

Leider führt das Aktualisieren des templates zu einem sehr merkwürdigem Fehlverhalten. Wenn ich den shellyflood manuell online bringe, werden einige Einträge in readingList verdoppelt, u. A. wird aber auch batteryPercent zu battery:

Code: [Auswählen]

defmod MQTT2_shellyflood_B08543 MQTT2_DEVICE shellyflood_B08543
attr MQTT2_shellyflood_B08543 IODev DaheimMQTT2
attr MQTT2_shellyflood_B08543 event-on-change-reading .*
attr MQTT2_shellyflood_B08543 icon humidity
attr MQTT2_shellyflood_B08543 jsonMap 1:report
attr MQTT2_shellyflood_B08543 model shellyflood
attr MQTT2_shellyflood_B08543 readingList shellies/MQTT2_shellyflood_B08543/online:.* online\
  shellies/MQTT2_shellyflood_B08543/announce:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  shellies/MQTT2_shellyflood_B08543/sensor/temperature:.* temperature\
  shellies/MQTT2_shellyflood_B08543/sensor/flood:.* flood\
  shellies/MQTT2_shellyflood_B08543/sensor/battery:.* batteryPercent\
  shellies/MQTT2_shellyflood_B08543/sensor/error:.* error\
  shellies/MQTT2_shellyflood_B08543/sensor/act_reasons:.* { json2nameValue($EVENT,'',$JSONMAP) }\
shellyflood_B08543:shellies/shellyflood-B08543/online:.* online\
shellyflood_B08543:shellies/announce:.* { json2nameValue($EVENT) }\
shellyflood_B08543:shellies/shellyflood-B08543/announce:.* { json2nameValue($EVENT) }\
shellyflood_B08543:shellies/shellyflood-B08543/sensor/temperature:.* temperature\
shellyflood_B08543:shellies/shellyflood-B08543/sensor/flood:.* flood\
shellyflood_B08543:shellies/shellyflood-B08543/sensor/battery:.* battery\
shellyflood_B08543:shellies/shellyflood-B08543/sensor/error:.* error\
shellyflood_B08543:shellies/shellyflood-B08543/sensor/act_reasons:.* { json2nameValue($EVENT) }
attr MQTT2_shellyflood_B08543 room MQTT2_DEVICE
attr MQTT2_shellyflood_B08543 setList x_update:noArg shellies/shellyflood-B08543/command update_fw\
  x_mqttcom shellies/shellyflood-B08543/command $EVTPART1
attr MQTT2_shellyflood_B08543 stateFormat [MQTT2_shellyflood_B08543:battery:t] - flood=[MQTT2_shellyflood_B08543:flood] (bat [MQTT2_shellyflood_B08543:batteryPercent]%)\

attr MQTT2_shellyflood_B08543 userReadings batteryX {if (ReadingsNum("MQTT2_shellyflood_B08543",  "batteryPercent", 0)>80) {return "ok"} else {return "low"}}

setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 - flood=false (bat [MQTT2_shellyflood_B08543:batteryPercent]%)\

setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:19 1 button
setstate MQTT2_shellyflood_B08543 2021-04-12 15:07:34 attrTemplateVersion 202010228
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 battery 100
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:19 batteryX low
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:19 error 0
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 flood false
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 fw_ver 20210323-105046/v1.10.1-gf276b51
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 id shellyflood-B08543
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 ip 192.168.178.55
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 mac 84CCA8B08543
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 model SHWT-1
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 new_fw false
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 online true
setstate MQTT2_shellyflood_B08543 2021-04-12 15:07:32 state x_mqttcom
setstate MQTT2_shellyflood_B08543 2021-04-12 17:27:18 temperature 19.62

Wenn ich manuell readingList korrigiere, wird das beim nächsten online wieder (automatisch) zunichte gemacht. Besonders blöd ist das Verschwinden von batteryPercent, so daß die battery low Erkennung nicht mehr tut (daher versuchsweise umbenannt in batteryX).

Vermutlich scheint in einer globalen Variable (JSONMAP z. B.?) die alten Werte weitervererbt zu werden?

In jedem Fall funktioniert jetzt shellyflood nicht mehr richtig. Ich habe aktuell keine Idee. Da das Gerät automatisch angelegt wurde, kann ichs wohl nicht einfach löschen und dann neu anlegen. Was nu?


Grüßle, Michael

[Beta-User]

lösche bitte nochmal die ganze readingList, starte den ESP durch und wende dann erst das attrTemplate an. Da ist irgendwas verbogen...

[olwaldi]

Danke für die schnelle Antwort. Habe schon vor Deiner Antwort die alten Werte von readingList wiederherstellen können, ohne JSONMAP. Damit habe ich das Verhalten von heute Morgen zurück:

Code: [Auswählen]

shellies/shellyflood-B08543/online:.* online
  shellies/shellyflood-B08543/sensor/temperature:.* temperature
  shellies/shellyflood-B08543/sensor/flood:.* flood
  shellies/shellyflood-B08543/sensor/battery:.* batteryPercent
shellyflood_B08543:shellies/announce:.* { json2nameValue($EVENT) }
shellyflood_B08543:shellies/shellyflood-B08543/announce:.* { json2nameValue($EVENT) }
shellyflood_B08543:shellies/shellyflood-B08543/sensor/error:.* error
shellyflood_B08543:shellies/shellyflood-B08543/sensor/act_reasons:.* { json2nameValue($EVENT) }Sieht für mich so aus, als wenn JSONMAP wohl der "Übeltäter" war.

Danke für Eure Geduld & Hilfe bei meinen Problemchen, Michael

[Beta-User]

Vermutlich ist jsonMap nicht der Übeltäter...

Aus irgendeinem Grund wurde da mal mit einem Unterstrich in der readingList gearbeitet, was aber (jetzt nicht mehr?) aktuell ist.

[olwaldi]

Fast geschafft?

Ich habe mal versuchsweise das json2nameValue für act_reasons weggelassen, und ich erhalte das Reading mit dem erhofften Namen act_reasons, allerdings als Liste in eckigen Klammern. D. h. schonmal, daß das Reading am richtigen topic "gesucht" wird. Mir ist auch klar, daß das Ganze in Kombination mit JSONMAP funktionieren sollte (probiere ich gerade aus). Mir ist nur unklar, warum man den "scheinbar" umständlichen Umweg über den Namen 1 gehen muß (und ob das Reading namens 1 übrigbleibt):

Code: [Auswählen]

attr shellyflood_B08543 jsonMap 1:act_reasons
attr shellyflood_B08543 readingList shellyflood_B08543:shellies/shellyflood-B08543/sensor/act_reasons:.* {json2nameValue ($EVENT, '', $JSONMAP)
Morgen dann ein Bericht, ob's so funktioniert (manuelles online-Schalten "kostet" zuviel Batteriekapa).

2020-04-14: Funktioniert wie erhofft (und schon weiter oben angeregt). Danke nochmal!


Grüßle, Michael

[olwaldi]

Ich möchte nochmal auf das Thema firmware update via fhem zurückkommen. Habe ziemlich lange gegoogelt und glaube, daß ein Firmware-Update durch ein

Code: [Auswählen]

set MQTT2_shellyflood_B08543 x_update angestoßen werden kann. Aber das funktioniert scheinbar beim Shellyflood nicht, da dieses Gerät immer nur kurz online geht, so daß wohl die MQTT-Kommandos nie ankommen. Laut logfile "erfährt" das Shellyflood nur kurz vorm offline-Gehen, daß eine neue Firmware verfügbar ist:

Code: [Auswählen]

2021-04-18_04:23:22 MQTT2_shellyflood_B08543 online: true
2021-04-18_04:23:22 MQTT2_shellyflood_B08543 new_fw: false
2021-04-18_04:23:22 MQTT2_shellyflood_B08543 temperature: 18.75
2021-04-18_04:23:37 MQTT2_shellyflood_B08543 new_fw: true
2021-04-18_04:25:12 MQTT2_shellyflood_B08543 online: falseAndereseits hätte fhem ein Zeitfenster von knapp 2min, um das update anzustoßen

Aktuell steht das Reading state auf x_mqttcom.

Hat jemand eine Idee, was ich in fhem noch tun kann zum Anstoßen eines firmware updates? Letzendlich ist das ein reines Komfort-Problem - kan natürlich in den Keller gehen und das update direkt am Shellyflood anstoßen.


Grüßle, Michael

[Beta-User]

Ich glaube ja nicht, dass man wirklich 2 Minuten hat, aber ein paar Sekunden nach "online: true" scheinen vorhanden zu sein...

Was hindert dich daran, auf das "online: true" ein notify anzusetzen, dass dann den update anschiebt, wenn new_fw false ist?

(Ich bezweifle, dass Batterie-betriebene updates bei WLAN-Geräten sinnvoll sind, aber machbar dürfte es auf diese Weise sein...)

[olwaldi]

Gute Idee. Ich habe vermutet, daß fhem das automatisch machen würde. Jetzt, wo ich weiß', daß nicht, werde ich Deine Anregung wie folgt umsetzen:

Code: [Auswählen]

define ShellyUpdate notify MQTT2_shellyflood_B08543:new_fw.*true set MQTT2_shellyflood_B08543 x_update
Was das Updaten mit Batterie angeht - das Shellyflood hat keine andere Stromversorgung. Und bislang haben 2 Updates problemlos geklappt (die Firmware ist wohl recht klein und in ein/zwei Minuten übertragen & installiert).


Danke, Michael

[olwaldi]

Hat leider nicht geklappt, die Firmware wurde nicht aktualisiert. Das notify hat aber wohl funktioniert

Code: [Auswählen]

2021.04.19 23:52:14 3: MQTT2_DEVICE set MQTT2_shellyflood_B08543 x_update
2021.04.19 23:53:49 3: DaheimMQTT2: DaheimMQTT2_192.168.178.55_13247/shellyflood-B08543 left us (keepalive check)
Vielleicht ist ja die online-Zeit doch zu kurz?

Andererseits ist mein Shellyflood bequem zugänglich, so daß ich dort manuell updaten kann.


Grüßle, Michael

[Beta-User]

Na ja, falls die Events noch so sind wie gezeigt, wäre er schon länger online, allerdings _vor_ dem Event, das du dir jetzt ausgesucht hast. Meine Anregung war:

auf das "online: true" ein notify anzusetzen, dass dann den update anschiebt, wenn new_fw false ist?

Also: anderer (zeitlich früherer) Trigger+if-Prüfung (Perl).

[olwaldi]

Ich habe bewußt auf das new_fw getriggert, da kurz nach dem online (laut Logfile) new_fs erstmal immer false  ist. Vermutlich dauert dann das aktuelle Prüfen auf Verfügbarkeit einer neuen Firmware vom Shelly im Internet 30..60s, dann triggert mein new_fs, aber das Shelly ist wohl schon wieder offline.

Alles Vermutungen meinerseits. Aktuell muß ich mich allerdings um was ganz Anderes kümmern. Wenn ich wieder Zeit habe, checke ich mal genauer die Reihenfolge der Events/Messages vom Shelly.


Grüßle, Michael

[Beta-User]

Na ja, wenn erst "false" kommt, muss man ggf. eine Iteration warten und einen internen Merker setzen, den man dann beim nächsten "online"-Event noch abfragen kann. Die Sendung muss noch vom Shelly kommen, wüßte nicht, wer sonst für so ein delay verantwortlich sein sollte.

Viel Spaß, bei dem was du vorhast.