Autor Thema: ShellyFlood  (Gelesen 9282 mal)

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
ShellyFlood
« am: 03 Januar 2020, 18:56:29 »
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%)
FHEM 6.1 auf RaspPi3 (Raspbian:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline enno

  • Sr. Member
  • ****
  • Beiträge: 922
Antw:ShellyFlood
« Antwort #1 am: 03 Januar 2020, 19:01:58 »
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
« Letzte Änderung: 03 Januar 2020, 19:06:16 von enno »
Einfacher FHEM Anwender auf Intel®NUC

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #2 am: 03 Januar 2020, 19:29:56 »
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).
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
Server: HP-T620@Debian 11, 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

Offline TomLee

  • Tester
  • Hero Member
  • ****
  • Beiträge: 4639
  • ... wer sät, der erntet ...
Antw:ShellyFlood
« Antwort #3 am: 03 Januar 2020, 19:41:03 »
Zitat
seit 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

Offline enno

  • Sr. Member
  • ****
  • Beiträge: 922
Antw:ShellyFlood
« Antwort #4 am: 03 Januar 2020, 19:47:55 »
Moin Thomas,

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
« Letzte Änderung: 03 Januar 2020, 19:50:04 von enno »
Einfacher FHEM Anwender auf Intel®NUC

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #5 am: 21 März 2020, 22:34:46 »
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 :-)

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #6 am: 21 März 2020, 22:39:14 »
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"}}
FHEM 6.1 auf RaspPi3 (Raspbian:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #7 am: 21 März 2020, 22:40:41 »
ach so, Beta-User hat ja ein template, das sollte sich von selbst anlegen!
FHEM 6.1 auf RaspPi3 (Raspbian:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #8 am: 22 März 2020, 09:54:11 »
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...
« Letzte Änderung: 22 März 2020, 10:13:03 von Mad »

Offline TomLee

  • Tester
  • Hero Member
  • ****
  • Beiträge: 4639
  • ... wer sät, der erntet ...
Antw:ShellyFlood
« Antwort #9 am: 22 März 2020, 10:56:26 »
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

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #10 am: 22 März 2020, 11:41:52 »
Tja, auch das funktioniert irgendwie nicht...
Hab den shelly auch mehrfach "aufgeweckt". Im MQTT.fx taucht er direkt auf. Fhem reagiert gar nicht...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #11 am: 22 März 2020, 11:50:03 »
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() }) }
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").
Server: HP-T620@Debian 11, 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

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #12 am: 22 März 2020, 11:56:31 »
Hallo Beta-User,
danke für die Nachricht. Schau dir doch bitte mal meine screenshots an. Vielleicht erkennst du das Problem?!

Offline TomLee

  • Tester
  • Hero Member
  • ****
  • Beiträge: 4639
  • ... wer sät, der erntet ...
Antw:ShellyFlood
« Antwort #13 am: 22 März 2020, 12:06:36 »
Steht was im LogFile ?

Passwort (wenn eingerichtet) vergessen in den MQTT-Einstellungen des Shellyflood einzutragen ?

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #14 am: 22 März 2020, 12:13:42 »
Im Logfile steht nichts zum flood. Passwort ist gesetzt, sonst könnte ich ihn ja nicht im MQTT.fx sehen.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #15 am: 22 März 2020, 12:24:31 »
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-T620@Debian 11, 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

Offline Mad

  • Jr. Member
  • **
  • Beiträge: 63
Antw:ShellyFlood
« Antwort #16 am: 23 März 2020, 21:38:09 »
So, konnte das Problem lösen. Einfach alles mal neustarten und es funktioniert.
Vielen Dank für die Hilfe!

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #17 am: 23 Juli 2020, 22:45:20 »
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:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #18 am: 24 Juli 2020, 08:03:29 »
...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-T620@Debian 11, 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

Offline enno

  • Sr. Member
  • ****
  • Beiträge: 922
Antw:ShellyFlood
« Antwort #19 am: 24 Juli 2020, 08:26:29 »
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

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #20 am: 26 Juli 2020, 09:33:51 »
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:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #21 am: 26 Juli 2020, 10:55:05 »
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-T620@Debian 11, 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

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #22 am: 27 Juli 2020, 13:54:01 »
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:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #23 am: 27 Juli 2020, 14:07:59 »
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-T620@Debian 11, 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

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #24 am: 27 Juli 2020, 14:12:43 »
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:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline enno

  • Sr. Member
  • ****
  • Beiträge: 922
Antw:ShellyFlood
« Antwort #25 am: 27 Juli 2020, 16:34:19 »
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

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #26 am: 27 Juli 2020, 18:16:58 »
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:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Krise

  • Jr. Member
  • **
  • Beiträge: 69
Antw:ShellyFlood
« Antwort #27 am: 11 Dezember 2020, 20:06:29 »
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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #28 am: 14 Februar 2021, 16:22:01 »
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?

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #29 am: 15 Februar 2021, 08:26:12 »
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.
« Letzte Änderung: 15 Februar 2021, 08:43:33 von olwaldi »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #30 am: 15 Februar 2021, 09:21:10 »
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.

Offline enno

  • Sr. Member
  • ****
  • Beiträge: 922
Antw:ShellyFlood
« Antwort #31 am: 15 Februar 2021, 11:24:08 »
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
Einfacher FHEM Anwender auf Intel®NUC

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #32 am: 16 Februar 2021, 07:59:00 »
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%.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #33 am: 16 Februar 2021, 08:54:52 »
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.
Zitat
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)...
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #34 am: 26 Februar 2021, 10:13:49 »
Noch eine Nachfrage zum ShellyFlood template: Alle Readings haben hübsche Namen, nur das erste nicht:
1     periodicbzw.
1     alarmHier 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


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #35 am: 26 Februar 2021, 10:22:22 »
Ä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...
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #36 am: 26 Februar 2021, 12:34:37 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #37 am: 26 Februar 2021, 13:04:28 »
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):
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.
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #38 am: 26 Februar 2021, 15:41:23 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #39 am: 26 Februar 2021, 16:46:39 »
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.
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #40 am: 27 Februar 2021, 16:25:10 »
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

Offline TomLee

  • Tester
  • Hero Member
  • ****
  • Beiträge: 4639
  • ... wer sät, der erntet ...
Antw:ShellyFlood
« Antwort #41 am: 27 Februar 2021, 16:37:08 »
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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #42 am: 28 Februar 2021, 09:40:12 »
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 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
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 shellyfloodaktiviert. 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
« Letzte Änderung: 01 März 2021, 17:15:04 von olwaldi »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #43 am: 11 April 2021, 08:39:11 »
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_updateeinspielen, 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

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8646
Antw:ShellyFlood
« Antwort #44 am: 11 April 2021, 19:30:20 »
Zitat
Hier hätte ich immer noch gern eine sinnvolle Bezeichnung anstelle von "1".Und kein Reading "-".
Was verhindert die Benutzung von userReading?

LG

pah


Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #45 am: 12 April 2021, 09:38:25 »
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

Offline TomLee

  • Tester
  • Hero Member
  • ****
  • Beiträge: 4639
  • ... wer sät, der erntet ...
Antw:ShellyFlood
« Antwort #46 am: 12 April 2021, 10:07:58 »
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.
« Letzte Änderung: 12 April 2021, 11:30:30 von TomLee »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #47 am: 12 April 2021, 16:03:41 »
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_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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #48 am: 12 April 2021, 17:43:15 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #49 am: 12 April 2021, 17:48:58 »
lösche bitte nochmal die ganze readingList, starte den ESP durch und wende dann erst das attrTemplate an. Da ist irgendwas verbogen...
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #50 am: 12 April 2021, 18:03:21 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #51 am: 12 April 2021, 18:08:38 »
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.
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #52 am: 13 April 2021, 16:50:53 »
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
« Letzte Änderung: 14 April 2021, 13:56:07 von olwaldi »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #53 am: 18 April 2021, 10:04:47 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #54 am: 18 April 2021, 17:24:45 »
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...)
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #55 am: 19 April 2021, 09:58:21 »
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
« Letzte Änderung: 19 April 2021, 13:08:17 von olwaldi »

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #56 am: 20 April 2021, 07:37:32 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #57 am: 20 April 2021, 07:51:59 »
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).
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #58 am: 20 April 2021, 18:16:11 »
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19718
Antw:ShellyFlood
« Antwort #59 am: 20 April 2021, 18:24:38 »
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.
Server: HP-T620@Debian 11, 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

Offline olwaldi

  • Full Member
  • ***
  • Beiträge: 197
Antw:ShellyFlood
« Antwort #60 am: 21 April 2021, 07:56:23 »
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

Offline andies

  • Tester
  • Hero Member
  • ****
  • Beiträge: 3452
Antw:ShellyFlood
« Antwort #61 am: 10 Dezember 2021, 19:53: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.
FHEM 6.1 auf RaspPi3 (Raspbian:  5.15.32-v7+); Perl: v5.28.1
SIGNALduino (433 MHz) und HM-UART (868 MHz)
wenige Brennenstuhl-IT, Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Offline Navigator

  • Sr. Member
  • ****
  • Beiträge: 622
Antw:ShellyFlood
« Antwort #62 am: 25 November 2022, 18:12:37 »
Kann man die "Floods" eigentlich auch ohne die MQTT Funktion ein FHEM einbinden? Mit aktiviertem MQTT verliert man ja die Cloud Funktion.

 

decade-submarginal