Hat den irgendjemand im Betrieb? Ich bin gespannt, wie lange die Batterie durchhält. Ansonsten liefert er
Internals:
CFGFN
CID shellyflood_765AC7
DEF shellyflood_765AC7
DEVICETOPIC shellyflood
FUUID 5e0f7294-f33f-0211-ee2c-d400a99fa450e3ff
IODev Mosquitto
LASTInputDev Mosquitto
MSGCNT 6
Mosquitto_MSGCNT 6
Mosquitto_TIME 2020-01-03 18:44:31
NAME shellyflood
NR 3530
STATE false (bat 93%)
TYPE MQTT2_DEVICE
Helper:
DBLOG:
temperature:
DbLog:
TIME 1578073471.13653
VALUE 14.62
READINGS:
2020-01-03 18:44:31 battery 93
2020-01-03 18:44:31 flood false
2020-01-03 18:44:31 online false
2020-01-03 18:44:31 temperature 14.62
Attributes:
IODev Mosquitto
readingList shellyflood_765AC7:shellies/shellyflood/online:.* online
shellyflood_765AC7:shellies/shellyflood/sensor/temperature:.* temperature
shellyflood_765AC7:shellies/shellyflood/sensor/flood:.* flood
shellyflood_765AC7:shellies/shellyflood/sensor/battery:.* battery
stateFormat flood (bat battery%)
Moin
seit ca drei Monaten zwei Stück:
Internals:
CID shellyflood_76527C
DEF shellyflood_76527C
DEVICETOPIC EG_K_Wassermelder
FUUID 5db9c0a1-f33f-9270-e9fd-92e0bda444a89534
IODev myBroker
LASTInputDev myBroker
MSGCNT 56
NAME EG_K_Wassermelder
NR 888
STATE false
TYPE MQTT2_DEVICE
myBroker_MSGCNT 56
myBroker_TIME 2020-01-03 15:06:50
Helper:
DBLOG:
temperature:
MYSQL:
TIME 1578060393.52629
VALUE 18.50
READINGS:
2019-11-21 10:42:42 battery ok
2020-01-03 15:06:33 batterylevel 100
2020-01-03 15:06:33 flood false
2020-01-03 15:06:33 fw_ver 20190917-131645/v1.5.5@45259d52
2020-01-03 15:06:33 id shellyflood-76527C
2020-01-03 15:06:33 ip 192.168.1.20
2020-01-03 15:06:33 mac DC4F2276527C
2020-01-03 15:06:33 new_fw false
2020-01-03 15:06:50 online false
2020-01-03 15:06:33 temperature 18.50
Attributes:
DbLogExclude .*
DbLogInclude flood,temperature
IODev myBroker
devStateIcon .*false:humidity@grey .*:humidity@red
event-on-change-reading .*
readingList shellyflood_76527C:shellies/shellyflood-76527C/online:.* online
shellyflood_76527C:shellies/announce:.* { json2nameValue($EVENT) }
shellyflood_76527C:shellies/shellyflood-76527C/sensor/temperature:.* temperature
shellyflood_76527C:shellies/shellyflood-76527C/sensor/flood:.* flood
shellyflood_76527C:shellies/shellyflood-76527C/sensor/battery:.* batterylevel
stateFormat flood
Gruss
Enno
attrTemplate-Vorschlag:
# shellyflood using original firmware
name:shellyflood
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellyht using original firmware <br>Just adds stateFormat and icon
order:A_16a
par:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
attr DEVICE icon ICON
attr DEVICE setList \
x_update:noArg shellies/DEVNAME/command update_fw\
x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
shellies/DEVNAME/online:.* online\
shellies/DEVNAME/sensor/temperature:.* temperature\
shellies/DEVNAME/sensor/flood:.* flood\
shellies/DEVNAME/sensor/battery:.* batteryPercent
attr DEVICE stateFormat flood (bat batteryPercent%)
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
attr DEVICE model shellyflood
Das icon ist kein ernst gemeinter Vorschlag, Vorschläge erbeten ;) ; batteryPercent sollte "kompatibler" sein (siene diese Vereinheitlichungsdiskussion (https://forum.fhem.de/index.php/topic,87575.0.html)).
Wenn das Zustimmung findet, würde ich auch den ht entsprechend anpassen (da war das feedback zur Batterielebensdauer aber eher durchwachsen, soweit ich mich entsinne).
Gruß, Beta-User
Zitatseit ca drei Monaten zwei Stück:
Und noch 100%. Sind das noch die ersten Batterien ?
Wie oft kommt denn die Temperatur rein, bei jeder Änderung ?
Gruß
Thomas
Moin Thomas,
Zitat von: TomLee am 03 Januar 2020, 19:41:03
Wie oft kommt denn die Temperatur rein, bei jeder Änderung ?
Ja ist noch die erste Batterie und nein nur zwei mal pro Tag bei mir.
Gruss
Enno
Hallo zusammen, ich habe auch zwei shellyflood, bekomme sie aber nicht in FHEM eingebunden.
Hab mehrere MQTT Geräte im Einsatz und sehe den shellyflood auch im MQTT.fx. Wie binde ich die floods in FHEM ein?
Bräuchte da etwas starthilfe :-)
hier meine Konfiguration. Deine wird anders sein, weil das devices anders heisst:
defmod shellyflood MQTT2_DEVICE shellyflood_765AC7 # <== aendern
attr shellyflood IODev Mosquitto # <=== aendern!!!
attr shellyflood readingList shellyflood_765AC7:shellies/shellyflood/online:.* online\
shellyflood_765AC7:shellies/shellyflood/sensor/temperature:.* temperature\
shellyflood_765AC7:shellies/shellyflood/sensor/flood:.* flood\
shellyflood_765AC7:shellies/shellyflood/sensor/battery:.* battery_no
attr shellyflood stateFormat flood
attr shellyflood userReadings battery {if (ReadingsNum($name, "battery_no", 0)>80) {return "ok"} else {return "low"}}
ach so, Beta-User hat ja ein template, das sollte sich von selbst anlegen!
Danke für die flotte Antwort. Ich habe das Problem, dass wenn ich den shellyflood als mqtt2 device anlege, mir kein shellyflood in den templates angezeigt wird. Es wird u.a. nur ein shelly1 angezeigt...
Wie und wo füge ich denn das template von beta-user ein?
Einfach in die mqtt2.template datei einfügen? Hab es so versucht, nach Neustart, kann ich dieses template auch nicht im device auswählen...
Hallo,
das Template wird nicht angezeigt weil du das Device von Hand angelegt hast und somit kein passendes ReadingList-Attribut existiert.
In dem Fall kannst du einfach das Template über die Kommandozeile aufrufen/anwenden:
set shellyflood attrTemplate shellyflood
Oder das von Hand angelegte Device wieder löschen und den Shellyflood automatisch anlegen lassen, indem du in vermutlich (hab keinen) einmal auslösen lässt.
Dann wird auch das Template angezeigt.
Gruß
Thomas
Tja, auch das funktioniert irgendwie nicht...
Hab den shelly auch mehrfach "aufgeweckt". Im MQTT.fx taucht er direkt auf. Fhem reagiert gar nicht...
Da fehlte was (bei dem HT auch...), s.u....
Hab's eben gefixt, update kommt morgen, bzw., wer's gleich haben will:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
Zitat von: andies am 21 März 2020, 22:40:41
ach so, Beta-User hat ja ein template, das sollte sich von selbst anlegen!
Das template war auch schon länger in der file, allerdings wird damit auch nichts "von selbst" angelegt, schon gleich nicht, wenn man das Device selbst von Hand anlegt und keine readingList vorhanden ist...
(@mad hat das vermutlich von Hand gemacht, weil er einen anderen Server nutzt als MQTT2_SERVER und das "Sortiertemplate" nicht nutzen will...? Wenn du das so machst wie von TomLee vorgeschlagen, mußt du halt jeweils den DEVNAME eingeben können (das hatte gefehlt...). Wert sollte aus den Infos zu entnehmen sein, die du in MQTT.fx siehst, in dem RAW von andies ist das "shellyflood").
Hallo Beta-User,
danke für die Nachricht. Schau dir doch bitte mal meine screenshots an. Vielleicht erkennst du das Problem?!
Steht was im LogFile ?
Passwort (wenn eingerichtet) vergessen in den MQTT-Einstellungen des Shellyflood einzutragen ?
Im Logfile steht nichts zum flood. Passwort ist gesetzt, sonst könnte ich ihn ja nicht im MQTT.fx sehen.
Hmm, alleine aus dem screenshot werde ich nicht schlau. Du hast versucht, "nichts" an den shelly zu senden, deswegen steht was in "state"?
Für den Rest (z.B., warum kein "online"-Status kommt), kann ich wenig sagen, da fehlen m.E. wesentliche Infos betreffend die "Elemente" zwischen dem mosquitto-Server (den ich hier nur indirekt als Schilderung aus MQTT.fx "zu sehen" bekomme) und dem MQTT2_DEVICE.
Das wären aber vermutlich Dinge, die nichts mit dem spezifischen Gerät zu tun haben, und daher m.E. hier OT sind (Mad ist nicht der TE! Sonst wäre es ok.).
Also: Wenn es ein MQTT2-"Erstling" ist (?), dann wäre meine Empfehlung, im Wiki bei MQTT2_CLIENT (das ist hoffentlich der TYPE von "mosquitto"?) anzufangen und da mal autocreate "simple" anzuschalten. Wenn es da schon Probleme gibt, bitte neuen Thread aufmachen.
So, konnte das Problem lösen. Einfach alles mal neustarten und es funktioniert.
Vielen Dank für die Hilfe!
Zitat von: enno am 03 Januar 2020, 19:47:55
Ja ist noch die erste Batterie und nein nur zwei mal pro Tag bei mir.
Also bei mir hat nun die erste Batterie nach wenigen Wochen aufgegeben: ziemlich genau sechs Monate, um genau zu sein.
...irgendwie ist das keine so große Überraschung, dass das Teil relativ viel Batterie-Leistung zieht...
WLAN ist eben keine energie-effiziente Funktechnik, da geht für jede Verbindung ziemlich viel Overhead über den Äther.
Moin,
bei mir senden beide noch wie zuvor zwei mal am Tag die Temperatur. Die Batterie soll laut Reading noch bei 100% sein. Das glaube ich erst mal nicht, aber die Termperaturdaten, die täglich kommen passen zum HM Thermometer im gleichen Raum. Ich werde heute Abend mal eines der Teile rausholen und ein Firmware Update machen. Die laufen immer noch mit der Firmware vom Januar.
Gruss
Enno
Ich habe jetzt die neue Batterie eingelegt, aber das Gerät wird nun von FHEM nicht mehr erkannt. Werkseinstellungen zurückgesetzt, auf autocreate gewartet - irgendwie passiert da nichts. Gibt es dort eine Art vorgeschriebenen Weg, wie man das macht? Ich befürchte, mein device ist hinüber.
Klingt nach einem Wiedergänger des HM-Batterie-Tod-Threads...?
(eQ-3 ist berühmt dafür, minderwertige Batterien auszuliefern; hast evtl. auch was erwischt, das dann das Device erwischt hat?)
Zitat von: Beta-User am 26 Juli 2020, 10:55:05
Klingt nach einem Wiedergänger des HM-Batterie-Tod-Threads...?
Das ist kein HM, das ist der bulgarische shelly. Inzwischen habe ich ihn mit der cloud vernetzt, kann aber nicht mehr auf ihn via FHEM zugreifen. In der weboberfläche ist auch nicht davon die Rede, die Cloud auszustellen (jedenfalls nicht am Gerät selbst). Ich komme hier nicht weiter. Ich weiß zB auch nicht, wo ich am Gerät MQTT einstelle?
Ich habe eine ältere Firmware (16.12.2019) und hoffe, dass es daran liegt. Bei der nächsten Batteriemeldung wird die aktualisiert. Aber wie habt Ihr denn den shelly in FHEM eingebunden? (Und wieso gelang mir das vor einem halben Jahr?)
Zitat von: andies am 27 Juli 2020, 13:54:01
Das ist kein HM, das ist der bulgarische shelly. Inzwischen habe ich ihn mit der cloud vernetzt, kann aber nicht mehr auf ihn via FHEM zugreifen. In der weboberfläche ist auch nicht davon die Rede, die Cloud auszustellen (jedenfalls nicht am Gerät selbst). Ich komme hier nicht weiter. Ich weiß zB auch nicht, wo ich am Gerät MQTT einstelle?
Ich habe eine ältere Firmware (16.12.2019) und hoffe, dass es daran liegt. Bei der nächsten Batteriemeldung wird die aktualisiert. Aber wie habt Ihr denn den shelly in FHEM eingebunden? (Und wieso gelang mir das vor einem halben Jahr?)
Ist schon klar, dass das ein anderer Hersteller ist; eQ-3 ist da aber auch keine völlige und unrühmliche Ausnahme, das Phänomen ist von anderen auch bekannt (auch wenn bei den shellys von 16 Monaten oder so die Rede ist; scheinbar sind selbst manche "Marken"-Batterien schlicht Sonder-Müll. Das Thema schlechte Batterien wurde hier eben schon ein paar Mal unter dem Label eQ-3 diskutiert, that's all...).
Lt. https://shelly.cloud/documents/user_guide/shelly_ht.pdf mußt du vermutlich den Deckel runtermachen, um das Ding in den AP-Mode zu versetzen, dann in die Experteneinstellungen?
Batterie ist neu (schon die zweite >:( ) und ich habe diese erweiterten Einstellungen nicht gefunden. Ich warte jetzt mal das Update ab und schaue dann mal, evtl komplett löschen und Werkseinstellungen.
Moin andies,
bin mal unter meinen Küchenschrank gekrabbelt und habe das Teil herausgezogen. Staubdicht ist es auf jedenfall 8)
Deckel abgeschraubt und den Taster rechts unten kurz betätigt. Kurze Zeit später ist das Teil über seine IP im Browser zu erreichen. Wo ich gerade drauf war kurz das Update eingespielt. The current Firmware version of your Shelly device is 20200625-102403/v1.7.3@2aa0993a No newer firmware available.
Unter Internet&Security "ADVANCED-DEVELOPER SETTINGS
aktiviert ist "Enable action execution via MQTT"
Beim Server die Adresse von FHEM drin, bei mir 192.168.175.250:1883
CLOUD ist deaktiviert!
Actions sind keine definiert
SNTP Server ist meine Fritzbox IP
Dannach bekommt FHEM das Teil zu sehen und legt es an, wenn es noch nicht vorhanden ist.
Akku ("GP Lithium" CR123A) ist auch am Gerät bei 100% die Readings in Fhem passen also. Da die Geräte ohne Akku von Shelly kommen, ist hier jeder seines Glückes Schmied. Wie schon geschrieben, ich habe immer noch die ersten Akkus in meinen beiden Geräten.
Grusss
Enno
Danke Enno, das mit dem kurzen Drücken war der entscheidende Tipp. Nun läuft alles wieder.
Mit Lithium Batterien hatte ich massive Probleme. Ich habe mir für eigentlich viel Geld bei Varta Lithium gekauft und die sind alle innerhalb kürzester Zeit verendet. Seitdem meine ich diese Batterieform. Vielleicht war es auch nur eine schlechte Charge, wer weiß. Die anderen "Long Life" von Varta sind teilweise schon 1,5 Jahre drin (alles keine Originalbatterien, die habe ich schnelle getauscht).
Moin,
ich habe auch testweise einen Flood im Test. Ich habe jetzt das Problem, dass er das Event "Flood" auslöst ohne Alarm am Gerät. Ich krieg nur ne Meldung über Fhem. Hat da einer Erfahrungen? Kann man die Länge des Event bestimmen, auf das getriggert wird.
Grüße
Christian
Habe seit heute einen ShellyFlood im Einsatz. Irgendwie komisch war das Initialisieren des Geräts selber. Ich kriegte recht schnell den lokalen Accesspoint zum Laufen, aber die Umstellung aufs heimische WLAN hat erst nach 3..4 Versuchen geklappt. Ein erster Firmware-Update ist irgendwieso gescheitert, hat dann aber doch geklappt. Alles in Allem hat das 16% Batterie gekostet. Seither läuft der ShellyFlood problemlos.
Mir ist allerdings aufgefallen, daß in FHEM der State als??? gemeldet wurde. Dank dieses Threads hier konnte ich das durch das Attribut stateformat flood lösen. Könnte das nicht im Template automatisch erfolgen? Temperatur, Wasser und Batteriezustand werden direkt perfekt an FHEM gemeldet.
Als Betriebsart habe ich Rain gewählt, obwohl ich ja eigentlich eine Warnung wg. Wasserrohrbruch sehen will. Nach meinem Verständnis gibts im Rain-Modus genau eine Meldung, wenn Wasser kommt bzw. wenn Wasser geht. Das ist m. M. n. das richtige Verhalten. Ansonsten gibt es (vermutlich) regelmäßig Meldungen (ala immer noch naß), richtig?
Ich habe mal nach ca. 16h nachgeguckt, ob sich der ShellyFlood automatisch rückmeldet. Hat er nicht getan. Könnte das daran liegen, daß ich den Temperatur-Threshold disabled habe?
Dann habe ich ihn mal auf ein nasses Tuch gestellt. Sofort erhalte ich eine flood-Meldung in FHEM. Perfekt!
Am Shelly blinkt die rote LED kurz mal beim Auslösen der flood und wiederum beim Entfernen des nassen Tuchs. Klar, es gibt auch 2 Meldungen in FHEM wie erwartet. Aber sollte der ShellyFlood nicht auch piepen? Oder wird das durch den Rainmode deaktiviert?
Nachtrag: Lustigerweise meldet der ShellyFlood jetzt wieder 100% battery😊 bei der flood-Meldung. Bin gespannt, wie sich das über die nächste Zeit entwickeln wird.
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.
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
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
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%.
Zitat von: olwaldi am 16 Februar 2021, 07:59:00
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.
ZitatSollte 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)...
Noch eine Nachfrage zum ShellyFlood template: Alle Readings haben hübsche Namen, nur das erste nicht:
1 periodic
bzw.
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)
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
Ä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...
Falls es hilft, hier ein list (irgendwoher (template?) haben die anderen Readings ja sinnvolle Bezeichnungen)
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
Was ist daran nicht konkret?
Zitat von: Beta-User am 26 Februar 2021, 10:22:22
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):
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.
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)
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
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.
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?)
{ReadingsVal("MQTT2_shellyflood_B08543", "1", "hmm")}
liefert periodic, während
{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
Du musst im dritten Parameter von json2nameValue $JSONMAP angeben damit jsonMap greift:
{ json2nameValue($EVENT,'',$JSONMAP) }
Hab keine Ahnung unter welchem Topic das Reading reinkommt, in einem dieser RL-Einträge halt:
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
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:shellyflood_B08543:shellies/shellyflood-B08543/sensor/1 report
Hat 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
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
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
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
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:
[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:
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
ZitatHier hätte ich immer noch gern eine sinnvolle Bezeichnung anstelle von "1".Und kein Reading "-".
Was verhindert die Benutzung von userReading?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 April 2021, 19:30:20
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
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
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 (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.
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
shellies/MQTT2_shellyflood_B08543/status/act_reasons
sprich' 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
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:
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
lösche bitte nochmal die ganze readingList, starte den ESP durch und wende dann erst das attrTemplate an. Da ist irgendwas verbogen...
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:
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
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.
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):
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
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 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:
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: false
Andereseits 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
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...)
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:
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
Hat leider nicht geklappt, die Firmware wurde nicht aktualisiert. Das notify hat aber wohl funktioniert
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
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:
Zitat von: Beta-User am 18 April 2021, 17:24:45
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).
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
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.
Update hat heute Nacht geklappt, ohne daß ich was ändern mußte, d. h. ich bleibe bei meinem notify, warte aber geduldiger, bis die online-Zeit "gereicht" hat. Und damit nicht jedes Update sofort eingespielt wird, habe ich das notify jetzt erstmal auf inactive gesetzt.
Ende gut, Alles gut, Michael
Zitat von: andies am 26 Juli 2020, 09:33:51
Ich habe jetzt die neue Batterie eingelegt
Und erneut nach sechs Monaten ist wieder eine neue Batterie fällig. ist ok.
Mein Spitzenreiter war eine Temperatursensor von TFA Dostmann, der hat noch nach drei Jahren gefunkt, als die 1,5V Batterien nur noch etwa 0,4V hatten. Das war unglaublich.
Kann man die "Floods" eigentlich auch ohne die MQTT Funktion ein FHEM einbinden? Mit aktiviertem MQTT verliert man ja die Cloud Funktion.
Hallo,
ich versuche den Flood Shelly einzubinden. Ich bekomme aber keine Verbindung zu dem Shelly.
Ich habe einen MQTT2 Server "erstellt" (ich hoffe es zumindest). Im Shelly habe ich bei I/O Aktionen die fhem IP Adresse und den Port angegeben:
http://192.168.2.16:1883
Kann mir einer weiterhefen, oder eine Anleitung zum Einbinden des Shelly Flood geben?
Ich habe schon eine Zeit gegoogelt und gesucht, doch keine passende Anleitung gefunden.
Shelly Flood Sensor:
Geräte ID 4c7525063fca
IP 192.168.2.14
List MQTTe Server:
Internals:
CFGFN
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 23
FUUID 64c92f43-f33f-7e98-b751-e027c680681ebf30
NAME MQTT2_FHEM_Server
NR 5246
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
.attraggr:
.attrminint:
.feedList:
1690906430.35924 1
1690954190.80724 1
1690958808.44051 1
1690990198.70173 1
1690992944.13033 1
1691031814.05675 1
1691074693.99245 1
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-08-01 18:13:55 nrclients 0
2023-08-01 18:13:55 state Initialized
clients:
retain:
Attributes:
autocreate complex
room FHEM
Vielen lieben Dank schon einmal,
Torsten
Die Shelly-Seite zeigt wohl das "actions"-feature?
MQTT ist eine andere Konfig-Seite....
Und unterlassen bitte Doppelpostings (ohne expliziten Hinweis)! https://forum.fhem.de/index.php?msg=1283283