ShellyFlood

[olwaldi]

Mittlerweile habe ich das Shelly Forum https://www.shelly-support.eu/forum/index.php?board/43-fhem/ gefunden. Und damit ist klar, daß der ShellyFlood im Rainmode nicht piepsen soll.

[enno]

Moin,

Ich habe immer noch die ersten Batterien drin. Siehe mein Post vom Juli. Die Anzeige steht noch bei 100%. Wenn ich das Teil aufwecke um ein Update zu machen geht es mal auf 89% runter, dann meldet es aber am nächsten Tag wieder 100%. Ich prüfe trotzdem die Aktivität (https://forum.fhem.de/index.php/topic,118712.msg1131538.html#msg1131538) , nicht dass das Teil bei 100% stehen bleibt und ausfällt. Das macht der Wassermelder von Homematic gerne mal.

Gruss
  Enno

[olwaldi]

Noch eine Nachfrage: Heute hat sich kurz vor 6Uhr (2021-02-16 05:58:51) mein ShellyFlood wie erwartet erstmalig automatisch zum Statusreport gemeldet. Soweit so gut. Aber kurz danach wird im Logfile gemeldet

Code Auswählen Erweitern

2021.02.16 06:00:26 3: DaheimMQTT2: DaheimMQTT2_192.168.178.55_60352/shellyflood-B08543 left us (keepalive check)
Auch das verstehe ich insofern, daß sich ja der ShellyFlood sofort wieder offline schaltet (Reading online false 2021-02-16 06:00:26).

Sollte ich noch irgendwas (was? wo?) bzgl. keepalive in MQTT2 einstellen?

BTW: battery ist immer noch auf 100%.

[Beta-User]

Auch das verstehe ich insofern, daß sich ja der ShellyFlood sofort wieder offline schaltet (Reading online false 2021-02-16 06:00:26).

Die Ursache für "offline" ist der Timeout iVm. der LWT-Konfiguration, der Log-Eintrag erklärt nur, warum bzw. dass es LWT-bedingt ist.

Sollte ich noch irgendwas (was? wo?) bzgl. keepalive in MQTT2 einstellen?

Diese Verhaltensweise kommt eher aus der Einstellung am ESP/der Shelly-"Hardware". "Eigentlich" sollte sich der Shelly imo entweder ordentlich abmelden, oder einen timeout ankündigen, der realistisch ist (dann würde das M2-IO auch den timer entsprechend lang setzen)...

[olwaldi]

Noch eine Nachfrage zum ShellyFlood template: Alle Readings haben hübsche Namen, nur das erste nicht:

Code Auswählen Erweitern

1     periodic
bzw.

Code Auswählen Erweitern

1     alarm
Hier sollte m.M.n. anstelle von 1 sowas wie type stehen. Vermutlich kann man das irgendwie im ShellyFlood-Template einstellen. Mir ist aber nicht klar, wie.

Mein Ziel ist dann, einen watchdog zu erstellen, der überprüft, ob sich der ShellyFlood mindestens 1x täglich gemeldet hat. Etwa so (schonmal mit type anstelle von 1)

Code Auswählen Erweitern

define WD_ShellyFlood watchdog MQTT2_shellyflood_B08543:type 24:00 MQTT2_shellyflood_B08543:type command
attr WD_ShellyFlood autoRestart
Auch hier bin ich dankbar für Korrekturen, sollte mein watchdog fehlerhaft sein. Insbesondere ist mir unklar, was der richtige Device-Name bei MQTT2-Geräten ist.

Grüßle, Michael

[Beta-User]

Ähm, ich "kann" zwar attrTemplate, habe aber keine Idee, wo das Reading "1" herkommt (so ist es doch gemeint, oder?). Mir fehlt schlicht die Hardware, das vorhandene Template ist aus den rudimentären Infos hier zusammengeschustert...

Wenn ich helfen soll, würde ich eine RAW-Definition benötigen und optimalerweise die Topics+Messages, die "periodic" bzw. "alarm" verursachen...

[olwaldi]

Falls es hilft, hier ein list (irgendwoher (template?) haben die anderen Readings ja sinnvolle Bezeichnungen)

Code Auswählen Erweitern

Internals:
   CID        shellyflood_B08543
   DEF        shellyflood_B08543
   DEVICETOPIC MQTT2_shellyflood_B08543
   DaheimMQTT2_MSGCNT 71
   DaheimMQTT2_TIME 2021-02-26 02:01:42
   FUUID      6029325a-f33f-6dde-c5a1-ff328a43ce7ceaa0
   IODev      DaheimMQTT2
   LASTInputDev DaheimMQTT2
   MSGCNT     71
   NAME       MQTT2_shellyflood_B08543
   NR         38
   STATE      false
   TYPE       MQTT2_DEVICE
   READINGS:
     2021-02-26 02:00:11   1               periodic
     2021-02-26 02:00:11   battery         100
     2021-02-26 02:00:11   error           0
     2021-02-26 02:00:11   flood           false
     2021-02-26 02:00:11   fw_ver          20201128-102432/v1.9.2@e83f7025
     2021-02-26 02:00:11   id              shellyflood-B08543
     2021-02-26 02:00:11   ip              192.168.178.55
     2021-02-26 02:00:11   mac             84CCA8B08543
     2021-02-26 02:00:11   model           SHWT-1
     2021-02-26 02:00:11   new_fw          false
     2021-02-26 02:01:42   online          false
     2021-02-26 02:00:11   temperature     17.62
Attributes:
   IODev      DaheimMQTT2
   event-on-change-reading .*
   readingList 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) }
   room       MQTT2_DEVICE
   stateFormat flood

Und da sieht man als Erstes das Reading 1. Das hat vermutlich zwei verschiedene Werte

• periodic, wenn's eine tägliche alive-Meldung ist
• alarm, wenn wirklich Wasser gemeldet wird

Mehr Infos habe ich nicht. Aber ich kann gern mehr beisteuern, wenn Du mir konkret sagst, was Du brauchst (und wie ich an die Infos komme).

Aber Danke schonmal für die schnelle Antwort, Michael

[Beta-User]

Was ist daran nicht konkret?

Wenn ich helfen soll, würde ich eine RAW-Definition benötigen und optimalerweise die Topics+Messages, die "periodic" bzw. "alarm" verursachen...

Langform:
- RAW-Definition => https://wiki.fhem.de/wiki/Import_von_Code_Snippets (dein list ist schon mal ein Anfang...)
- Topics+Messages, die "periodic" bzw. "alarm" verursachen => du musst den MQTT-Verkehr mitschneiden, geht z.B., indem man rawEvents am IO ("DaheimMQTT2") erzeugt und dann am Event-Monitor entsprechend filtert oder sonst eine Methode verwendet, um den MQTT-Verkehr mitzuschneiden. Ich bin Traditionalist und verwende dazu mosquitto_sub (gibt ne manpage dazu, da steht auch, wie man es mit "verbose" startet).

Evtl. hilft ja das hier (RAW-Def, siehe oben):

Code Auswählen Erweitern

attr MQTT2_shellyflood_B08543 readingList shellies/shellyflood-B08543/online:.* online\
  shellies/announce:.* { json2nameValue($EVENT) }\
  shellies/shellyflood-B08543/announce:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  shellies/shellyflood-B08543/sensor/temperature:.* temperature\
  shellies/shellyflood-B08543/sensor/flood:.* flood\
  shellies/shellyflood-B08543/sensor/battery:.* batteryPercent\
  shellies/shellyflood-B08543/sensor/error:.* error\
  shellies/shellyflood-B08543/sensor/act_reasons:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_shellyflood_B08543 jsonMap 1:report

An ein paar Stellen bin ich ratlos:
- welchen Zweck hat "flood"- welche der $JSONMAPs greift (vermute: act_reasons)

Anm.:
- batteryPercent ist "unser Standard"... (https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings)
- CID in der readingList ist kein "Muss", deleted for portability reasons.

[olwaldi]

Vielleicht ja ein Mißverständnis: ich bin nur User, und das Einzige, was ich gemacht habe, war das Anlegen des ShellyFlood Devices. Die technischen Details kenne ich nicht, das meiste het FHEM automatisch gemacht. Ich wollte im Wesentlichen nur "nett" sein und mir aufgefallene kleinere Mängel melden. Bin selber Softwareentwickler (gewesen) und habe mich immer geärgert, wenn Anwender Fehler nichtmal gemeldet haben.

Hier mal die raw-Definition (das Device hat sich automatisch angelegt, wohervsollre ich auch die ID kennen)

Code Auswählen Erweitern

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 readingList 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 stateFormat flood

setstate MQTT2_shellyflood_B08543 false
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 1 periodic
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 battery 100
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 error 0
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 flood false
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 fw_ver 20201128-102432/v1.9.2@e83f7025
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 id shellyflood-B08543
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 ip 192.168.178.55
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 mac 84CCA8B08543
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 model SHWT-1
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 new_fw false
setstate MQTT2_shellyflood_B08543 2021-02-26 02:01:42 online false
setstate MQTT2_shellyflood_B08543 2021-02-26 02:00:11 temperature 17.62




Grüßle, Michael

[Beta-User]

Vorab: Ich freue mich, wenn ich Hinweise bekomme, wenn was nicht optimal ist.

Vielleicht zur Klarstellung bzgl. "Mängel:
solange du einfach nur "autocreate" machen läßt, kommt da ggf. ein "unschönes" device raus, aber meistens ist es (irgendwie) funktional; was im einzelnen rauskommt, hängt vom "Datenlieferanten" ab, also dem, was so ein Device schickt. Das ist teils über verschiedene firmware-Versionen auch nicht konstant, bei den attrTemplate ist da immer der Versuch dahinter, das für die aktuelle firmware irgendwie dann so hinzubiegen, dass es - aus FHEM-Sicht - "schön" ist.

Mit deinem Input kann ich jetzt schon mal "auf Verdacht" das attrTemplate verbessern. Ob es dann "gut" ist, kannst du ja dann rückmelden; ohne die Rohdaten (MQTT-Verkehr) kann ich halt nur aus den Readings und Zeitstempeln Rückschlüsse auf die Ausgangsdaten ziehen, das reicht oft.

Aber so oder so war der watchdog "verbogen", da war - soweit erkennbar - nie ein Event "type". Dazu solltest du mal den "Event-Monitor" bemühen und versuchen, (vielleicht mit einem gesprächigeren Device) die Syntax zu verstehen; über den Event-Monitor hast du auch Zugriff auf "eventTypes" und kannst das dann ggf. auch für den flood anpassen (wenn dann die "korrigierten" Events "schöner" sind). Hier ist das aber OT, bitte ggf. einen neuen Thread im Anfängerbereich aufmachen.

[olwaldi]

Ich habe gerade mal Deinen Vorschlag mit jsonMap 1:report ausprobiert. Scheint zunächst keine Wirkung zu haben (oder muß ich bis zur nächsten Meldung des ShellyFlood warten?)

Code Auswählen Erweitern

{ReadingsVal("MQTT2_shellyflood_B08543", "1", "hmm")}
liefert periodic, während

Code Auswählen Erweitern

{ReadingsVal("MQTT2_shellyflood_B08543", "report", "hmm")}
hmm liefert.

Ich guck' morgen nochmal nach, ob das Mapping nach einer neuen Meldung des ShellyFlood wirkt.

Grüßle, Michael

[TomLee]

Du musst im dritten Parameter von json2nameValue $JSONMAP angeben damit jsonMap greift:

Code Auswählen Erweitern

{ json2nameValue($EVENT,'',$JSONMAP) }

Hab keine Ahnung unter welchem Topic das Reading reinkommt, in einem dieser RL-Einträge halt:

Code Auswählen Erweitern

shellyflood_B08543:shellies/announce:.* { json2nameValue($EVENT) }
shellyflood_B08543:shellies/shellyflood-B08543/announce:.* { json2nameValue($EVENT) }
shellyflood_B08543:shellies/shellyflood-B08543/sensor/act_reasons:.* { json2nameValue($EVENT) }

Gruß

Thomas

[olwaldi]

Habe Deinen Tip für alle drei Readings ausprobiert, Editieren von readingList in der GUI, Speichern der Änderung durch OK und Drücken von attr, Reload der Web-Seite mit den Readings des ShellyFlood. Aber die 1 bleibt eine 1.
Oder gälte hier, daß ich bis zur nächsten NEUEN Meldung warten muß?
Aus der Doku für MQTT2_DEVICE würde ich herauslesen, daß man "einfach" so einen Eintrag hinzufügen müßte:

Code Auswählen Erweitern

shellyflood_B08543:shellies/shellyflood-B08543/sensor/1 reportHat aber auch nicht funktioniert.
Für mich spielt's aber auch keine wirklich wesentliche Rolle, wenn das Reading weiterhin 1 heißt. Ich werde jetzt erstmal mit watchdogs weiterexperimentieren...

Mittlerweile habe ich die API-Doku von Shelly gefunden unter https://shelly-api-docs.shelly.cloud/#shelly-flood-settings-actions
Dort gibts die act_reasons als Bestandteil von /status - im readingList steht aber /sensor

Code Auswählen Erweitern

shellyflood_B08543:shellies/shellyflood-B08543/sensor/act_reasons:.* { json2nameValue($EVENT)
Auch hier hat das Ändern von sensor auf status in readingList leider keinen unmittelbaren Effekt.

Noch ein Nachtrag: Bislang hatte ich noch nicht das shellyflood template entdeckt, jetzt aber durch

Code Auswählen Erweitern

set MQTT2_shellyflood_B08543 attrTemplate shellyflood
aktiviert. Damit kann ich meine obige Frage schonmal selber beantworten - readingList wirkt erst auf neue MQTT Botschaften. Aber auch mit dem shellyflood Template bleibt mir ein Reading namens 1 erhalten.

Danke für eure Geduld, Michael

[olwaldi]

Ich habe mal wieder einige Fragen zum shellyflood - nur kleinere Unschönheiten:

1.Vor Kurzem gabs ein Firmwareupdate vom Hersteller. Das wollte ich durch ein

Code Auswählen Erweitern

set MQTT2_shellyflood_B08543 x_update
einspielen, ohne Effekt. Da die shellyfloods fast immer offline sind, wird der zugehörige MQTT-Befehl vermutlich gar nicht empfangen. Versuchsweise habe ich einen Alarm simuliert, um ein Online zu erzwingen. Hat aber keinen Firmwareupdate ausgelöst. Danach habe ich manuell (erfolgreich) die Firmware aktualisieten können. Allerdings steht seither das Reading state auf x_update. Rein aus kosmetischer Sicht, wie kann ich hier den normalen Wert zurückbekommen?

2.Ich nutze stateFormat, um eine hübsche Darstellung der Info zu haben:

Code Auswählen Erweitern

[MQTT2_shellyflood_B08543:battery:t] - flood=[MQTT2_shellyflood_B08543:flood] (bat [MQTT2_shellyflood_B08543:batteryPercent]%)
Funktioniert prima. Aber wenn ich aus irgendeinem Grund fhem restarte, erhalte ich als Anzeige drei Fragezeichen. Erst ein Neusetzen von stateFormat (auf denselben Wert) reaktiviert die Darstellung wieder.

3.Nach wie vor heißt das Reading für den Typ der Online-Meldung "1". Obendrein gibts das neue Reading namens "-", nachdem ich stateFormat geändert habe. Dort steht der formatierte String drin:

Code Auswählen Erweitern

Internals:
   CID        shellyflood_B08543
   DEF        shellyflood_B08543
   DEVICETOPIC MQTT2_shellyflood_B08543
   FUUID      6029325a-f33f-6dde-c5a1-ff328a43ce7ceaa0
   IODev      DaheimMQTT2
   NAME       MQTT2_shellyflood_B08543
   NR         38
   STATE      2021-04-10 18:01:25 - flood=false (bat 100%)

   TYPE       MQTT2_DEVICE
   READINGS:
     2021-04-10 18:01:25   -               flood=false (bat 100%)
     2021-04-10 17:59:47   1               periodic
     2021-03-01 08:23:41   attrTemplateVersion 20200522 or prior
     2021-04-10 18:01:25   battery         ok
     2021-04-10 17:59:47   batteryPercent  100
     2021-04-10 17:59:47   error           0
     2021-04-10 17:59:47   flood           false
     2021-04-10 17:59:47   fw_ver          20210323-105046/v1.10.1-gf276b51
     2021-04-10 17:59:47   id              shellyflood-B08543
     2021-04-10 17:59:47   ip              192.168.178.55
     2021-04-10 17:59:47   mac             84CCA8B08543
     2021-04-10 17:59:47   model           SHWT-1
     2021-04-10 17:59:47   new_fw          false
     2021-04-10 18:01:25   online          false
     2021-04-03 10:51:09   state           x_update
     2021-04-10 17:59:47   temperature     18.88
Attributes:
   IODev      DaheimMQTT2
   event-on-change-reading .*
   icon       humidity
   model      shellyflood
   readingList 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) }
   room       MQTT2_DEVICE
   setList    x_update:noArg shellies/shellyflood-B08543/command update_fw
  x_mqttcom shellies/shellyflood-B08543/command $EVTPART1
   stateFormat [MQTT2_shellyflood_B08543:battery:t] - flood=[MQTT2_shellyflood_B08543:flood] (bat [MQTT2_shellyflood_B08543:batteryPercent]%)

   userReadings battery {if (ReadingsNum("MQTT2_shellyflood_B08543",  "batteryPercent", 0)>80) {return "ok"} else {return "low"}}
Hier hätte ich immer noch gern eine sinnvolle Bezeichnung anstelle von "1".Und kein Reading "-".


Grüßle, Michael

[Prof. Dr. Peter Henning]

Hier hätte ich immer noch gern eine sinnvolle Bezeichnung anstelle von "1".Und kein Reading "-".

Was verhindert die Benutzung von userReading?

LG

pah