ShellyFlood

Begonnen von andies, 03 Januar 2020, 18:56:29

Vorheriges Thema - Nächstes Thema

Beta-User

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

Mad

So, konnte das Problem lösen. Einfach alles mal neustarten und es funktioniert.
Vielen Dank für die Hilfe!

andies

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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

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

enno

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
Einfacher FHEM Anwender auf Intel®NUC

andies

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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

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

andies

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?)
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

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

andies

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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

enno

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
Einfacher FHEM Anwender auf Intel®NUC

andies

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).
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Krise

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

olwaldi

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?

olwaldi

#29
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.