Modul 36_ShellyMonitor

[Beta-User]

Ich weiß jetzt nicht, wo die Diskussion geführt werden sollte, aber gerne hier:

M.E. ist sie hier wirklich an der falschen Stelle, aber sei's drum, dann hake ich mich mal mal hier ein...

Ich empfehle fuer solche Faelle das neu angelegte Geraet per ignore Attribut zu verstecken. Die FHEM-Systemlast duerfte ohne autocreate hoeher sein, weil in diesem Fall fuer jede, von diesen Geraeten empfangene Nachricht, ein "global UNDEFINED" Event generiert wird.

Interessanter Aspekt, kommt auf meine "Liste"...

Ich habe bei FHEM mit [...] angefangen, und ohne zu wissen, was da passiert, habe ich es als gottgegeben [...]

...so ähnlich ging's mir auch mal, nur eben mit CUL_HM... Erst viel später habe ich da das Thema VCCU entdeckt, mit dem man manches abfangen kann (auch wenn es über der Zeit teilweise komisch ist, was da so eintrudelt).

Zwischenzeitlich habe ich auch autocreate wieder eingeschaltet, und ja, hin und wieder kommt da auch immer mal wieder was "neues vom Nachbarn" (oder manchmal - eher häufiger wie das andere - auch ein ZWave-Irrläufer oder eine kaputte MQTT-Message).

Die gleiche User-Experience hatte ich mit MQTT: Sch.-Name, aber wenn man was neu eingebunden hat, sucht man das neu kreierte Device, weiß nicht, ob man es umbenennen darf, vergibt sicherheitshalber einen Alias. Richtig nett fand ich, als ich bei MQTT das erste Mal durch Popups durch Fragen nach Attributen - sogar mit alexaName - durchgeführt wurde.

Dem 2. Teil liest man doch gern ...
Wobei diese alexa-Name-Sache relativ wenig mit MQTT2_DEVICE zu tun hat, diesen Teil der attrTemplate-files findet man getrennt zum Rest und kann ihn auch für andere Device-TYPE aufrufen, MAX macht das z.B. auch . Wenn also Shelly SetExtensions mitbringt, könnte man das auch (versteckt) im Hintergrund aufrufen (wenn nicht via global ausgeschaltet)!
(Das betrifft btw. auch das, was in general_use.template zu finden ist (das macht zusätzliche Devices für weitere Kanäle und setzt associatedWith entsprechend).

Nämlich mit der Liste: "Hey, dass hier habe ich gefunden: Wähle einen Namen, und dann geht es los". Diese User-Experience könnte / sollte / hätte aber eigentlich modul-übergreifend da sein: Ein Spezial-Room "New kids in town", in dem alles auftaucht, was neu ist und von dem FHEM der Meinung ist: "Klick hier, gib einen Namen und ggf. noch Attribut xy ein - dann definieren wir das!".

Na ja, in Teilen kann man das auch im TYPE=autocreate heute einstellen, ich habe z.B. das automatische erstellen des FileLog ausgeschaltet. Zum Rest bin ich mal auf Vorschläge gespannt...

Da könnte z.B. eine über UPnP-Broadcasts erkannte Hue-Bridge zu gehören, oder die MÄXchen, oder MQTT-Clients, oder eben von Shelly-Monitor erkannte Shellies. Und natürlich das, was an den USB-Ports eindeutig zugewiesen werden kann.

Ich bin doch vermutlich nicht der Erste, der diese Idee hat, oder?

Nein.
U.A. Loredo (?) hatte afaik mal an was Universellem gearbeitet, k.A., wer da noch mit an Bord war. Habe das (ungeprüft) unter dem Stichwort "Installer" im Kopf, erkennen sollte das ggf. auch UPnP (?).
Für USB gibt's "seit immer" initialUSBCheck (bzw. den Befehl "usb" aus dem autocreate-Modul), der aber bekanntermaßen nicht nur Segen mit sich bringt; die "Krux" bei USB ist das Thema Baudrate, je nach Gegenstelle dauert es eine Zeitlang, bis da was zurückkommt, FHEM muss bei jeder Änderung warten, bis die MCU wieder erreichbar ist. Könnte man ggf. vom Ablauf her optimieren, das ganze ist aber im Detail schwierig, und m.E. stellt sich da die Grundsatzfrage, ob es den Aufwand wert ist, das umzubauen...

Falls jemand Details zu attrTemplate haben will (grade bei User-Abfragen kann es tricky sein, das hinzubiegen, da können auch andere ein Liedchen von singen): feel free.
Falls das jemand im Detail interessiert: Bin grade am Testen, wie man das Toolset nutzen kann, um beliebige Devices (konkret: aus MQTT_GENERIC_BRIDGE heraus) (teilweise) zu konfigurieren. Man braucht halt ein "Aufhängerdevice", das AttrTemplate-Support mitbringt (ggf. auch via SetExtensions).

[Wzut]

Ich empfehle fuer solche Faelle das neu angelegte Geraet per ignore Attribut zu verstecken. Die FHEM-Systemlast duerfte ohne autocreate hoeher sein, weil in diesem Fall fuer jede, von diesen Geraeten empfangene Nachricht, ein "global UNDEFINED" Event generiert wird.

Wenn es um "echte" Geräte geht mag das ok sein, aber bei manchen Funkprotokollen ist es mit der Absicherung Länge/CRC nicht so weit her ( Bsp MAX ) und da kann durchaus ein zerstörtes Telegramm ein Device anlegen das dann in 100 Jahren nicht wieder auftaucht.   

[Beta-User]

Hmm, ist es nicht so, dass man bei den zweistufigen Modulen (teilweise) am IO einstellen kann, ob das autocreate-Flag mitgegeben werden soll?
(Zumindest die MQTT2-IO's macht das so, und auch MYSENSORS, (das aber einen anderen dispatch-Mechanismus verwendet und daher ggf. nicht hierher gehört); für ZWDongle würde ich mir das im Moment wünschen, wobei das alle paar Wochen mal ein "readingloses" Device ist, das da hochpoppt...).
Dann wäre das ggf. ein (möglicher) Ansatzpunkt, "help me" etc. zu vermeiden...?

Ist aber hier wirklich ziemlich OT...

[enno]

Moin,

ich habe heute Morgen das Update gemacht. Es läuft alles, Die Daten kommen an. Jetzt habe ich nur noch die Hinweise im Log. Gibt es einen Trick die abzustellen? Meine Lösung wäre Verbose 0 aber vielleicht geht es eleganter.

Code Auswählen Erweitern

2021.01.20 16:45:07 2: Defined real device Thermo_DG_DB_Shelly for 192.168.179.174 as model generic
2021.01.20 16:45:07 1: Assigning device Thermo_DG_DB_Shelly SHELLYID E0143E
2021.01.20 19:02:28 2: Defined real device Thermo_OG_Shelly for 192.168.179.175 as model generic
2021.01.20 19:02:28 1: Assigning device Thermo_OG_Shelly SHELLYID E00DA8
2021.01.20 19:39:43 2: Defined real device EG_K_Wassermelder_Shelly for 192.168.179.172 as model generic
2021.01.20 19:39:43 1: Assigning device EG_K_Wassermelder_Shelly SHELLYID 76527C
2021.01.20 20:22:41 2: Defined real device Thermo_DG_GZ_Shelly for 192.168.179.173 as model generic
2021.01.20 20:22:41 1: Assigning device Thermo_DG_GZ_Shelly SHELLYID E01BD6
2021.01.20 20:35:06 2: Defined real device KG_WK_Wassermelder_Shelly for 192.168.179.171 as model generic
2021.01.20 20:35:06 1: Assigning device KG_WK_Wassermelder_Shelly SHELLYID 694936
2021.01.20 21:13:14 1: Device EG_K_Wassermelder_Shelly has expired, no messages seen
2021.01.20 21:13:14 1: Device Thermo_DG_DB_Shelly has expired, no messages seen
2021.01.20 21:13:14 1: Device Thermo_OG_Shelly has expired, no messages seen

Gruss
  Enno

[gvzdus]

Ich baue heute oder morgen mal ein "Override" für die TTL für die Batterie-Shellys ein. Dank Deiner Meldung ihrer ID kann ich sie ja erkennen und den Allterco-Flaw umschiffen. Ich denke mal, mit wirklich neuen Geräten oder wirklich verschwundenen Shellys kannst Du im Logfile leben.

P.S. Ist eingetragen: Für die von Dir genannten DevIDs wird jetzt die TTL auf 90.000 Sekunden "überbügelt". Sollte morgen da sein, Rückmeldung willkommen, Bugreport an Allterco geschickt.

Code Auswählen Erweitern

svn diff
Index: 36_ShellyMonitor.pm
===================================================================
--- 36_ShellyMonitor.pm (Revision 23563)
+++ 36_ShellyMonitor.pm (Arbeitskopie)
@@ -241,7 +241,12 @@
     "SHBDUO-1" => "widgetOverride ct:colorpicker,CT,2700,10,6500"
);

+my %DEVID_TTL_OVERRIDE = (
+    "SHWT-1"   => 90000,
+    "SHHT-1"   => 90000
+);

+
# SHWT-1 = Shelly Flood, should go to generic

my %ROLLER_STATUS_MAP = (
@@ -489,13 +494,13 @@
       }
     }

+    # Header parsed, processing data...
+    my ($devtype, $devid, $devversion) = split (/#/, $global_devid);
+
     foreach ( @devrefs ) {
-      $_->{expires} = time()+$validity;
+      $_->{expires} = time() + ( $DEVID_TTL_OVERRIDE{$devtype} // $validity );
     }

-    # Header parsed, processing data...
-    my ($devtype, $devid, $devversion) = split (/#/, $global_devid);
-
     # Handle ignoring of devices
     my $ignoreRegexp = $hash->{".ignoreDevices"};
     if ($ignoreRegexp) {


[gvzdus]

Ich habe heute von Allterco folgende Geräte erhalten:

• Shelly Duo Color
• Shelly Button
• Shelly i3

Der Duo Color lief auf Anhieb nach richtiger Konfiguration des model ("shellybulb"), was ab morgen dann natürlich automatisch geht. Ich habe noch den Bug behoben, dass die Farbtemperatur ("colorTemp" / "ct"), wenn nicht über mod_shelly geändert, sondern über die WebGUI des Devices (oder Cloud ...), nicht zurückgeschrieben wurde.

Der Shelly Button hat Unschönheiten. Zunächst ist wieder - wie beim Flood und H&T - die TTL 3840 Sekunden. Das Gerät übermittelt je nach Anzahl und / oder Länge der Knopfdrücke ein Event "S", "SS" oder "SSS" (kurzer Druck), oder "L" ("LL" und "LLL" gibt es wohl nicht). Außerdem kommt ein Event-Counter. Dieser zählt - ist das Gerät am Lader - fortlaufend hoch. Heißt: Im Lademodus wäre die weitere Verarbeitung in FHEM auf einen Knopfdruck:

Code Auswählen Erweitern

... notify shelly-button:inputEventCnt_0.* { Lese das Reading "inputEvent_0" und handele danach }

Denn da Shelly und ShellyMonitor nur geänderte Werte als Event generieren, wäre der Counter das auslösende Ereignis, und inputEvent_0 gleichbleibend ohne Event, wenn erneut ein kurzer Knopfdruck erfolgte. So weit, so gut.

Zieht man aber den Strom ab, ist bei jedem Knopfdruck der EventCounter 1 (offenbar: Events, seit ich aufgewacht bin), und das Event selber natürlich auch wieder "S". Heisst: Hier käme gar nichts an Events.

Ich muss mal überlege, wie man da "workarounden" kann. Dazu muss ich mindestens abwarten, wie sich das Viech "blind" meldet, also aus Langeweile statt wegen eines Knopfdrucks.

List der Device-Readings:

Code Auswählen Erweitern

     2021-01-21 14:38:46   battery         84
     2021-01-21 14:46:58   cfgChanged      0
     2021-01-21 14:46:58   charger         0
     2021-01-21 14:38:45   cloud           disabled
     2021-01-21 14:38:45   firmware        ?
     2021-01-21 14:46:58   inputEventCnt_0 1
     2021-01-21 15:01:55   inputEvent_0    L
     2021-01-21 15:08:57   network         not connected
     2021-01-21 14:38:46   sensorError     0
     2021-01-21 15:08:57   state           Error
     2021-01-21 14:46:58   wakeupEvent     button

[enno]

Ich habe eben mal mutig den Gassensor eingesteckt: generic (SHGS-1)

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.179.23
   DURATION   0
   FUUID      60099321-f33f-9270-caa0-65f7b2ff060cc2c6
   INTERVAL   600
   NAME       shelly_generic_shgs_1_50029178b7a2
   NR         22063
   SHELLYID   shellygas-50029178B7A2
   STATE      initialized
   TCPIP      192.168.179.23
   TYPE       Shelly
   Helper:
     DBLOG:
       network:
         MYSQL:
           TIME       1611240225.14857
           VALUE      <html>connected to <a href="http://192.168.179.23">192.168.179.23</a></html>
       state:
         MYSQL:
           TIME       1611240225.14857
           VALUE      initialized
   READINGS:
     2021-01-21 15:43:46   cfgChanged      1
     2021-01-21 15:43:46   cloud           disabled
     2021-01-21 15:43:46   concentration   0
     2021-01-21 15:43:46   firmware        v1.8.0(update needed to v1.9.0)
     2021-01-21 15:43:46   gas             none
     2021-01-21 15:43:45   network         <html>connected to <a href="http://192.168.179.23">192.168.179.23</a></html>
     2021-01-21 15:43:46   selfTest        not_completed
     2021-01-21 15:43:46   sensorOp        normal
     2021-01-21 15:43:45   state           initialized
     2021-01-21 15:43:46   valve           not_connected
Attributes:
   DbLogExclude .*
   interval   600
   model      generic
   room       20 Alarmanlage,Shelly

Gruss
  Enno

[enno]

Wenn du mir sagst wo  TTL auf 90.000 Sekunden "übergebügelt" steht, dann schaue ich nach.

Gruss
  Enno

[gvzdus]

"TTL wird überbügelt" merkst Du, wenn Du heute morgen aktualisiert hast, und morgen in Deinem Logfile keine Löschung und Neu-Auftauchen von nicht definierten Shelly H&T oder Shelly Floods steht Sie werden jetzt erst gut 1 Tag nach der letzten Meldung vergessen. Shelly Gas wird natürlich erst mit dem Update morgen "TTL überbügelt"

[gvzdus]

Die Version morgen hat etwas mehr Lametta für neu angelegte Shelly 1pm, Dimmer 2 und Duos. Siehe Screenshot. Geringfügig angepasst übernommen aus den AttrTemplates für MQTT.

[Prof. Dr. Peter Henning]

Dazu muss ich mindestens abwarten, wie sich das Viech "blind" meldet, also aus Langeweile statt wegen eines Knopfdrucks.

Etwa 1x am Tag.


Übrigens habe ich in einem anderen Thread auch schon vorgeschlagen, dass man mal schaut, was sonst noch so über Broadcast/Multicast hereinkommt.

https://forum.fhem.de/index.php/topic,114457.msg1120455.html#msg1120455

LG

pah

[gvzdus]

Ja, und ich habe den Vorschlag, "weder händisch Devices konfigurieren, noch automatisches AutoCreate, sondern Erkennen, Vorschlagen, Input abfragen und asynchron anlegen" ja auch verschoben.

Aber 2 grundsätzliche Dinge:
Richtig gut gefällt mir die Lampen-Integration für die Lampen von Shelly noch nicht. Das ist ja auch - bis auf RGB - eher neu. Im Kern sind es zwei Punkte:

• Der mode-Wechsel zwischen Farb- und Weiß-Modus, der beim Shelly ja sogar automatisch verläuft, wenn man eine "weiße Farbe" einstellt.
• Bei MQTT muss ich noch ausprobieren, wie es mit den zeitgenössischen Templates klappt. Zumindest bei meinem veralteten ShellyBulb, wo ich das MQTT-Template geschrieben habe, war es so, dass das Setzen von "pct" / "brightness" auf > 0 auch ein Einschalten implizierte. Dafür gibt es Pros und Cons.
  Pro: Ein Befehl - viel einfacher in Alexa. Niemand hat Lust, "Alexa schalte das Licht auf 50%. Alexa, schalte das Licht ein" zu sagen.
  Contra: Bei den Fluren, wo ich zweistufig vom Initialwert (30%) nach einer Minute auf einen Dimmwert (12%) fahre, bevor nach weiteren 60 Sekunden das Licht ausgeht, gehe ich extra vor dem Ausschalten auf 30%, um dann direkt danach "off" zu senden

Zum Architektonischen und an Enno gerichtet:
Bei mir geht ohne FHEM keine Heizung und die TK-Truhe taut auf. Und weil meine Solarthermieregelung im Eimer ist, überlege ich, die auch auf FHEM zu legen. Das hängt alles an einem Raspi. Du hängst jetzt Wasser- und Gas-Sensoren daran.
Ich würde Dir für so kritische Geräte eine redundante Konfiguration mit MQTT *und* ShellyMonitor empfehlen. Idealerweise auf 2 Raspis - denn das ist m.E. der größte Vorteil vom Konzept des Shelly-Modul - neben (noch) einfacherer Einrichtung: Die Möglichkeit redundanter Steuerung parallel zu Shelly-Cloud oder eben einem 2. Raspi.
MCast wird der Shelly immer los werden, bei MQTT - was erst P2 in der Bearbeitung hat - wird er es hartnäckiger versuchen - über den einzelnen Paketverlust im Netzwerk hinaus.

[enno]

Zum Architektonischen und an Enno gerichtet:

Bei mir läuft Heizung und Warmwasser auch ohne FHEM. Kühlschrank, Tiefkühler und Waschmaschine melden nur, die HM und Shelly schalten bei Stromausfall und Strom wieder da automatisch an. Auch ohne FHEM. Wenn FHEM stehen sollte und nichts geht mehr, werde ich von meiner Mitbewohnerin vor die Tür gesetzt Daher macht FHEM alles mehr smart aber zur Not geht es auch ohne. Dafür gibt es dann in allen Zimmern Lichtschalter und Heizungsthermostate...

Gasmelder meldet sich recht laut durch Piepsen. Das ist ok für die Anwohner.

Wassermelder werde ich dann noch mal im zweiten FHEM auf Raspi per MQTT einbinden. Das Hauptsystem läuft auf einem NUC. Ich bin aber gerade dabei das ganze in einen Proxmox Container umzuziehen.

Gruss
  Enno

[Prof. Dr. Peter Henning]

Eigentlich sind wir damit OT.

ei mir geht ohne FHEM keine Heizung und die TK-Truhe taut auf.

Never ! Solche Systeme müssen stabil und autonom laufen. Und wenn sie dafür einen eigenen Pi Zero bekommen, auch gut.

LG

pah

[gvzdus]

Etwa 1x am Tag.

Inzwischen sind > 24h seit meinem letzten Button-Klick vergangen...
Ich finde übrigens nichts, wo man ein Intervall einstellen könnte, indem er "Pieps" sagt. Habe ich das in der GUI eventuell übersehen? Beim H&T kann man es ja (naheliegenderweise) einstellen, auch beim Shelly Flood oder Shelly Gas?