FHEM Forum

Dieses Modul wertet Multicast-Messages aus, die jedes Shelly-Gerät i.d.R. alle 30 Sekunden und bei wichtigen Zustandsänderungen im Netzwerk sendet.
Diese Pakete werden für 2 Zwecke verwendet:

• Readings in Geräten, die mit 36_Shelly.pm angelegt wurden, werden aktualisiert. Das Pollen im Shelly-Modul kann daher auf eine sehr niedrige Frequenz gestellt werden - z.B. um Readings wie verfügbare Firmwareupdates anzuzeigen.
• Auf der Übersichtsseite des "ShellyMonitor-Gerätes" selber wird eine Tabelle aufgebaut, in der alle gefundenen Shellys im Netzwerk aufgeführt werden. Bereits definierte Geräte werden mit ihrem Namen aufgeführt, neuen Geräten kann ein Name zugewiesen werden, und sie werden dann mit einem Klick als Shelly-Modul-Gerät angelegt (siehe auch Screenshot)

Einrichtung
define shellymon ShellyMonitor
Sollte sich trotz vorhandener Shellys danach keine Tabelle aufbauen, weil keine Geräte auf dem primären Netzwerkinterface gefunden werden, kann es nötig sein, das Gerät zu löschen und mit
define shellymon ShellyMonitor <interface>
anzulegen - z.B. "wlan0" als Interface.

Unterstützte Geräte
Soweit bekannt, werden alle Shelly-Geräte, die Mod_Shelly kennt, unterstützt. Nicht in Mod_Shelly bekannte Gerätemodelle werden als "generic"-Modell angelegt und alle im Netz publizierten Reading-Updates in das Gerät geschrieben.

Die Geräteerkennung erfolgt anhand der "Global Device Id" im Multicast-Paket. Im verbose-5-Modus werden diese Pakete geloggt. Verbesserungsvorschläge sind willkommen, insbesondere, wenn die "Global Device Id" bekannt ist. Dies ist in der Zeile
URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=22563
z.B. das SHPLG-S

Das Modul ist ab 17.01.2021 in der aktuellen FHEM-Version enthalten

Hallo,

etwas merkwürdiges ist grad bei mir passiert, ich weiß nicht, ob das am ShellyMonitor-Modul oder am FHEM liegt, denn die fhem.pl ist auch upgedatet worden. Ich lege das Device an:


define ShellyMonitor ShellyMonitor


Dann wird das Device erzeugt und angezeigt. Es finden sich auch schon bekannte shellys, bei save config kommt das Fragezeichen, oben im Reiter dreht und dreht es sich. Dann einen kurzen Moment später ist die Seite blank, das Fragezeichen bei save config ist weg und wenn ich dann ein list ShellyMonitor absetze, sagt er, es gäbe kein solches Device... also neu angelegt, und so weiter, immer im Kreis...

Wenn ich einen Dummy anlege, passiert sowas nicht...

Hast du eine Idee ?

Grüße

Christian

Ich habe mit einem sekundenfrisch aktualisierten FHEM genau Deinen Befehl abgesetzt und kann es nicht reproduzieren.
Einzig vorstellen kann ich mir, dass es sonderbare Effekte gibt, wenn durch ShellyMonitor ein FHEMWEB-Reload getriggert wird und Du gleichzeitig auf etwas klickst. Deswegen warte vielleicht einmal 40 Sekunden, bis alle Shelly-Devices gefunden wurden (sie senden normalerweise alle 30 Sekunden). Dann sollte kein Reload mehr ausgelöst werden.

...nach dem x-ten Versuch konnte ich tatsächlich speichern, bevor die Seite wieder refreshed wurde... und noch eine Frage hätte ich: Ich hatte das so verstanden, dass das Modul Readings in die angelegten Shelly-Devices schreibt, richtig ? Ich habe 6 Devices, Shelly1, Shelly 2 und Shelly2.5 sowie einen Dimmer. Aber: ich habe in keinem der Devices irgendein neues Reading gefunden, auch nach 15 Minuten nach der Define vom Shellymonitor... Sollte das so richtig sein ?

Grüße

Christian

Moin, prima. Ich habe mich bemüht, möglichst nur die Readings zu aktualisieren, die auch pah im Shelly-Modul "zieht". D.h.: Wenn Du z.B. ein "energy"-Reading hast, oder ein "power"-Reading mit häufig wechselnden Werten: Das sollte definitiv refreshed werden.
Nicht getestet ist allerdings:
Wenn hingegen ein Device auf model generic steht, dann sollte ShellyMonitor alles aus dem Netz in Readings schreiben.
Da Du ja nach den Sensoren beim 1PM suchst: Du kannst das mal so testen:
1) ShellyMonitor löschen
2) Shelly1PM-Device auf model generic umstellen
3) ShellyMonitor neu definieren
Dann *sollten* Readings im Shelly1PM-Device auftauchen. Der Umweg "Löschen, Ändern, Neu anlegen" ist nötig, weil ShellyMonitor das "model"-Attribut cacht. Dass Du die Seite eines Devices neu laden musst, um neue Readings zu sehen, weißt Du?

Ja, war mir bekannt, ich hatte die Devices aus dem Monitor neu aufgerufen, daher sollten die Readings da aktualisiert worden sein, dachte ich... Aber wenn sowieso nur die "normalen" Readings aktualisiert werden, ist das ganze für mich eher weniger interessant....

Aber danke für deine Hilfe anyway...

Grüße

Christian

Zitat von: gvzdus am 17 Januar 2021, 12:58:08
Moin, prima. Ich habe mich bemüht, möglichst nur die Readings zu aktualisieren, die auch pah im Shelly-Modul "zieht". D.h.: Wenn Du z.B. ein "energy"-Reading hast, oder ein "power"-Reading mit häufig wechselnden Werten: Das sollte definitiv refreshed werden.

Moin,
wie sollten denn die Readings angezeigt werden? Ich habe 16 Devices gefunden (Plugs und Shelly1), aber außer der Tabelle mit den angelegten Namen, den IPs sowie dem Modell bekomme ich keine weiteren Informationen. Es werden nur die empfangenen MSGs hochgezählt, z.B. Stausänderungen o.ä. gibt es nicht...

Internals:
   CFGFN     
   FD         25
   FUUID      600432e5-f33f-378b-0b52-13f8547e658c4c09
   NAME       Shelly.Monitor
   NOTIFYDEV  global
   NR         1656
   NTFY_ORDER 50-Shelly.Monitor
   STATE      Statistics: 3189 msg received, 0 broken, 0 ignored, 16 devices
   TYPE       ShellyMonitor
   READINGS:
     2021-01-17 14:41:45   state           Statistics: 3189 msg received, 0 broken, 0 ignored, 16 devices
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   group      Shelly
   room       System->Geräte

Gruß, Christoph

Die Seite ist nur eine Übersichtsseite. Wenn Du auf das einzelne Gerät gehst, siehst Du die Readings. Sie werden halt sobald aktualisiert, sobald eine Nachricht eintrifft, und nicht erst, wenn das Pollintervall abgelaufen ist.

Beispielsweise solltest Du bei Deinen Sonos-Shellyplugs, wenn Du auf die Geräteseite gehst und ein bissel an der Lautstärke spielst, gleich im power-Reading die Veränderung des Stromverbrauchs sehen.

Hm, wenn ich das jetzt richtig sehe, wird damit also das "normale" Shelly-Device geöffnet, aber über das ShellyMonitor-Device werden die Readings auch bei einem Intervall=43200 (1/2 Tag) trotzdem sofort aktualisiert, wenn sich was ändert?

Gruß, CHristoph

Richtig!
Du kannst das Poll-Intervall gigantisch hochdrehen, die Readings sind so aktuell wie mit MQTT.
Vorteil ggü. MQTT sehe ich darin, dass z.B. der Parallelbetrieb mit der Shelly-Cloud möglich ist, oder auch mehrere FHEM-Instanzen auf das gleiche Gerät zugreifen können.

Hab mich schon sehr auf das Modul gefreut, genau das was ich suche. Leider killt es reproduzierbar mein fhem :(

Ich habe acht shellyplug-S. Nachdem ich das Modul definiere, sehe ich von den shelly's die IPs reinrauschen.  Nach einigen Sekunden ist fhem nicht mehr erreichbar. Im log findet sich folgendes:

Can't use string ("Wohnzimmer") as a HASH ref while "strict refs" in use at ./FHEM/36_ShellyMonitor.pm line 722.


"Wohnzimmer" ist einer meiner definierten rooms (wollt ich nur festhalten auch wenns eh klar sein dürfte).

Danke für Deinen Test! Diese Meldung kenne ich, und ich wollte sie vor dem Launch beheben. Letztlich konnte ich es nicht eingrenzen. Ich habe dafür zwar "Sicherheitszeilen" im Code eingebaut, aber die scheinen nicht zu greifen. Kannst Du mir aus dem fhem.log sagen, in welcher Zeile FHEM abgestürzt ist? Du hast noch eine Stelle gefunden, und ich rätsele, wo der Fehler reinkommt.

kann ich etwas beitragen um den Fehler zu finden? loglevel hochdrehen? oder andere Ideen?

Nein, ich habe den Fehler bei mir selber auch bei Loglevel 5 nicht eingrenzen können, aber auch nicht reproduzieren können.
Die gerade eben ins SVN eingestellte Version prüft bei jedem Cache-Lesen die Datentypen - damit fange ich hoffentlich den Fehler ab.

Außerdem habe ich Joachims Punkt behoben: Das Modul erkennt IP-Wechsel von Shelly-Geräten und aktualisiert die Definition in FHEM. Joachim war aufgefallen, dass das nicht für noch nicht angelegte Geräte gilt: Die tauchten bei einem IP-Wechsel doppelt auf. Ist jetzt geändert.

Wenn Du die angehängte Version vorab testen kannst, wäre es gut - sonst ist sie morgen per Update verfügbar.

Ich werde das heute Abend (wenn tatsächlich Zeit ist/bleibt) mal testen...
...und außerdem: hänge ich jetzt hier auch "dran" :)

Gruß, Joachim

Zitat von: gvzdus am 18 Januar 2021, 09:38:55Wenn Du die angehängte Version vorab testen kannst, wäre es gut - sonst ist sie morgen per Update verfügbar.

hab sie gerade eingespielt ... läuft perfekt! Vielen Dank für den schnellen fix!

Wenn man ein solches Modul baut und eincheckt, das zusätzliche, vom FHEM Standard abweichende perl Pakete (Multicast) voraussetzt, sollte man diese Abhängigkeiten auch in der commandref beschreiben!

Ist erledigt und in der Version morgen drin.

Zitat von: MadMax-FHEM am 18 Januar 2021, 10:34:05
Ich werde das heute Abend (wenn tatsächlich Zeit ist/bleibt) mal testen...
...und außerdem: hänge ich jetzt hier auch "dran" :)

Gruß, Joachim

So: "gesagt getan" ;)

Also IP-Adresse ändern geht :)  (sofern die Shelly dann auch irgendwann mal mit der neuen IP Messages verschicken, da ist wohl bei "denen" noch was "verquer")

Allerdings stimmt die Anzahl an "Devices" nicht mehr.

Also: alte IP -> 1 Device / IP ändern -> 2 Devices usw.

Nicht schlimm aber etwas "verwirrend"...

Und: wie kann ich Devices aus der Tabelle löschen?

Mal angenommen (was ich ja zum Testen, okok ;)  öfter vorkommt) ich habe mal einen Shelly in Betrieb genommen und dann beschlossen, dass ich ihn doch nicht brauche oder er defekt ist (hatte ich bei einem der Shelly 1L / gekauft, angeschlossen und gemerkt, dass "Schalter-Eingang-1" einen Defekt hat: ging nicht)...

Wie werde ich den jemals wieder los?

Aktuelle "Lösung": delete ShellyMonitor / define ShellyMonitor... (unschön)

Gruß, Joachim

Hi Joachim,
Geräte, die nicht mehr da sind, sollten nach etwa 65 Minuten verschwinden. Die Multicast-Pakete enthalten eine TTL, im verbose 5-Log als "validity" aufgeführt werden. Die werte ich aus, und nach Ablauf sollte das Gerät in der Tabelle verschwinden:
URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=57406

Ah, ok, zu ungeduldig ;)

Andere Alternative: Device anlegen und dann löschen... Damit ist es aus der Liste raus und kommt/käme erst wieder, wenn es neu sendet.

Also passt...

Gruß, Joachim

Hallo, habe ich es richtig verstanden, dass das Modul nur Readings und das Shelly Modul schreibt, die dort auch aufgeführt sind?

Konkret: ich habe einen Shelly1 mit AddOn Temperatur und Feuchte und bei anderen Modulen auch on/off werden vom Shelly übertragen aber nicht im Shelly Modul übernommen?

Probier's aus. Wenn die Werte nicht ankommen, leg' ein zweites Gerät mit der gleichen IP an, und weise ihm das Model "generic" zu. Dann sollte alles ankommen.

Sorry, aber so umständlich benötige ich es nicht. Die fehlende Daten hole ich mir über HTTPMOD und füge sie mir per userReadings ins Gerät. Dafür brauche ich kein Modul, wo ich dann ein Gerät doppelt anlegen muss.

Und wie sollte ich ein neues Gerät anmelden, er kennt es doch schon (so deute ich den Bildschirmausdruck)

Ich verstehe wirklich den Sinn dieses Moduls nicht.

pah hat sich bei Mod_Shelly entschieden, einige Werte wie die Chiptemperatur in Celsius und Fahrenheit zu ignorieren. Gegen diese ästhetische Entscheidung möchte ich nicht besserwisserisch verstoßen.

Gleichzeitig haben wir das "generic"-Model aus der Taufe gehoben, das *alles* erhält. Damit sollte jedes sensorhafte Shelly-Gerät (Bewegungsmelder, Flood, Gas u.s.w.) unterstützt werden. Allerdings fehlt mir dazu Feedback.

Ein weiteres Shelly-Gerät kannst Du natürlich anlegen, indem Du "define zweitgeraet Shelly ip" absetzt, und dann dem Gerät das Model "generic" zuweist. Eine andere Möglichkeit, zu sehen, was gesendet wird, ist, auf "verbose 5" im Shelly-Monitor zu gehen - das wird aber geschwätzig im Logfile.

Natürlich kannst Du alternativ mit HTTPMOD pollen, aber das ist Engineeringaufwand und CPU-Overhead, und z.B. für Bewegungsmelder durch die Verzögerung nicht gefühlsecht.

Ebenso "holt" ein userReadings am Shelly-Device die Daten vom HHTPMOD-Device ja auch nur, wenn es getriggert wird durch eine Änderung am Shelly-Device.

Und da es verm. kein "passendes Trigger Reading" dort gibt hast du verm. ein userReadings ohne expliziten Trigger was dann u.U. öfter (als nötig) "läuft" und verm
"veraltete" Daten holt.
Weil verm. HTTPMOD-Zyklus und userReadings-Trigger nie "zueinander passen"...

Aber niemand "zwingt" dich das zu nutzen... ;)

Gruß, Joachim

Seit der Monitor bei mir läuft habe ich vorlaufend folgende Art von Meldungen im Logfile

2021.01.19 09:53:36 2: Defined real device XXXXXXXXX for 192.168.X.XX as model shelly2.5
2021.01.19 09:53:37 1: Panic, it happened: Cache for 192.168.X.XX did contain a none-hash

Wie kann ich das abstellen ?

Eine weitere Frage
Wie kann ich dafür Sorgen, das die Seite vom ShellyMonitor Device nicht andauernd refreshed wird.
Ich kann sonst keine Einstellungen am Device vornehmen (nicht mal den Raum ändern) weil vor Auswahl des Raumes schon ein Refresh durchgeführt wird.

Zitat von: gvzdus am 18 Januar 2021, 22:51:54
Hi Joachim,
Geräte, die nicht mehr da sind, sollten nach etwa 65 Minuten verschwinden. Die Multicast-Pakete enthalten eine TTL, im verbose 5-Log als "validity" aufgeführt werden. Die werte ich aus, und nach Ablauf sollte das Gerät in der Tabelle verschwinden:

Code Auswählen Erweitern

URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=57406

Das ist problematisch, z.B. für Floods und DW's, die sich eventuell nur alle 6 Stunden melden (bei mir im Normalfall erst nach 24 Stunden).
Besser wäre es dafür die Geräte zu markieren und dem Benutzer das Löschen zu überlassen, damit sie nicht immer erscheinen und verschwinden.

Du hast das Szenario von Wetterhexe, was jetzt ohne Crash abgefangen wird.
Ich hatte es einmal auch bei mir und konnte es nicht reproduzieren. Die eine Bitte: Schalte ShellyMonitor auf "verbose 5" und schicke mir bitte eine Minute Logfile vor dem Crash. Da Anhänge per Pmail nicht gehen, vielleicht direkt an gvz Klammeraffe garnix.de .
Alternativ kann liebend gerne jemand einen Code-Review durchführen und mir um die Ohren hauen, wie ich in der Hash -> Array -> Hash - Welt mich verhaspelt habe und das Array einen String statt einer Hash-Referenz enthält. Ich vermute: Auf der IP, die in der Panic-Zeile aufgeführt wird, liegt ein reales und definiertes Device? So war es bei mir.

Das "ewige" Reload ist ein Folgefehler. Da laufend der Eintrag wieder weggemüllert und neu angelegt wird, ist nicht nach 30 Sekunden, wenn alle Geräte gefunden wurden, Ruhe.

Das ist problematisch, z.B. für Floods und DW's, die sich eventuell nur alle 6 Stunden melden (bei mir im Normalfall erst nach 24 Stunden).

Ich gehe davon aus, dass Floods & Co. hier eine höhere Validity-Periode senden, denn dafür ist der Wert ja angegeben und variabel. Ich habe allerdings keine entsprechenden Geräte, und bisher immer nur den "gut 1 Stunde"-Wert gesehen.

Für die Freunde der Perl-Denksportaufgabe:

    if (! @devices ) {
      Log3 ($name, 4, "$sending_ip not found in cache");
      # Search for defined devices by IP:
      @devices = ();
      my @devNames = devspec2array("TYPE=Shelly:FILTER=DEF=$sending_ip");
      foreach ( @devNames ) {
        my $model = AttrVal($_, "model", "generic");
        my %d = (
          name       => $_ ,
          isDefined  => 1,
          model      => $model,
          mode       => AttrVal($_, "mode", undef)
        );
        push @devices, \%d;
        Log3 $name, 2, "Defined real device $_ for $sending_ip as model $model";
      }
      my $ip2devices = \@devices;
      $hash->{".ip2device"}->{$sending_ip} = $ip2devices;
      $ip2devicesDirty = 1;
    }

Ich verstehe einfach nicht, wie hier im Array letztendlich statt einer Hashreferenz ein String landen kann...

Zitat von: gvzdus am 19 Januar 2021, 10:09:47
Du hast das Szenario von Wetterhexe, was jetzt ohne Crash abgefangen wird.
Ich hatte es einmal auch bei mir und konnte es nicht reproduzieren. Die eine Bitte: Schalte ShellyMonitor auf "verbose 5" und schicke mir bitte eine Minute Logfile vor dem Crash. Da Anhänge per Pmail nicht gehen, vielleicht direkt an gvz Klammeraffe garnix.de .
Alternativ kann liebend gerne jemand einen Code-Review durchführen und mir um die Ohren hauen, wie ich in der Hash -> Array -> Hash - Welt mich verhaspelt habe und das Array einen String statt einer Hash-Referenz enthält. Ich vermute: Auf der IP, die in der Panic-Zeile aufgeführt wird, liegt ein reales und definiertes Device? So war es bei mir.

Das "ewige" Reload ist ein Folgefehler. Da laufend der Eintrag wieder weggemüllert und neu angelegt wird, ist nicht nach 30 Sekunden, wenn alle Geräte gefunden wurden, Ruhe.


2021.01.19 10:20:58 4: Received data from 192.168.0.22
2021.01.19 10:20:58 4: 192.168.0.22 not found in cache
2021.01.19 10:20:58 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 10:20:58 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 10:20:58 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8545
2021.01.19 10:20:58 5: Found device Couch, model shelly2
2021.01.19 10:20:58 5: Found device Esstisch, model shelly2
2021.01.19 10:20:58 5: cfgChanged = 0
2021.01.19 10:20:58 5: output_0 = 0
2021.01.19 10:20:58 5: output_1 = 0
2021.01.19 10:20:58 5: input_0 = 0
2021.01.19 10:20:58 5: inputEvent_0 =
2021.01.19 10:20:58 5: inputEventCnt_0 = 0
2021.01.19 10:20:58 5: input_1 = 0
2021.01.19 10:20:58 5: inputEvent_1 =
2021.01.19 10:20:58 5: inputEventCnt_1 = 0
2021.01.19 10:20:58 5: power_0 = 0
2021.01.19 10:20:58 5: energy_0 = 10297
2021.01.19 10:20:58 5: overpowerValue = 0
2021.01.19 10:20:58 5: overpower_0 = 0
2021.01.19 10:20:58 5: overpower_1 = 0
2021.01.19 10:20:58 5: mode = relay
2021.01.19 10:20:59 4: Received data from 192.168.0.50
2021.01.19 10:20:59 4: 192.168.0.50: in cache, devices=LichtTreppeE_1 (size=1)
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHSW-1#1D97D9#2, validity=3840, serial=24
2021.01.19 10:20:59 5: Found device LichtTreppeE_1, model shelly1
2021.01.19 10:20:59 5: cfgChanged = 1
2021.01.19 10:20:59 5: output_0 = 0
2021.01.19 10:20:59 5: input_0 = 1
2021.01.19 10:20:59 5: inputEvent_0 =
2021.01.19 10:20:59 5: inputEventCnt_0 = 0
2021.01.19 10:20:59 4: Received data from 192.168.0.115
2021.01.19 10:20:59 4: 192.168.0.115: in cache, devices=Trockner_16A (size=1)
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHPLG2-1#2F562B#2, validity=3840, serial=3735
2021.01.19 10:20:59 5: Found device Trockner_16A, model shellyplug
2021.01.19 10:20:59 5: cfgChanged = 2
2021.01.19 10:20:59 5: output_0 = 1
2021.01.19 10:20:59 5: power_0 = 0
2021.01.19 10:20:59 5: energy_0 = 0
2021.01.19 10:20:59 5: overpower_0 = 0
2021.01.19 10:20:59 5: overpowerValue = 0
2021.01.19 10:20:59 4: Received data from 192.168.0.51
2021.01.19 10:20:59 4: 192.168.0.51: in cache, devices=LichtTreppe1_2 (size=1)
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHSW-1#1D908C#2, validity=3840, serial=8
2021.01.19 10:20:59 5: Found device LichtTreppe1_2, model shelly1
2021.01.19 10:20:59 5: cfgChanged = 1
2021.01.19 10:20:59 5: output_0 = 0
2021.01.19 10:20:59 5: input_0 = 0
2021.01.19 10:20:59 5: inputEvent_0 =
2021.01.19 10:20:59 5: inputEventCnt_0 = 0
2021.01.19 10:20:59 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 10:20:59 1: Panic, it happened: Cache for 192.168.0.31 did contain a none-hash
2021.01.19 10:20:59 4: Received data from 192.168.0.14
2021.01.19 10:20:59 4: 192.168.0.14 not found in cache
2021.01.19 10:20:59 2: Defined real device Spuelmaschine for 192.168.0.14 as model shellyplug
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHPLG-S#3CF173#2, validity=3840, serial=4098
2021.01.19 10:20:59 5: Found device Spuelmaschine, model shellyplug
2021.01.19 10:20:59 5: cfgChanged = 1
2021.01.19 10:20:59 5: output_0 = 1
2021.01.19 10:20:59 5: power_0 = 0.59
2021.01.19 10:20:59 5: energy_0 = 178916
2021.01.19 10:20:59 5: overpower_0 = 0
2021.01.19 10:20:59 5: overpowerValue = 0
2021.01.19 10:20:59 5: deviceTemp = 28.08
2021.01.19 10:20:59 5: deviceTemp = 82.54
2021.01.19 10:20:59 5: overtemp = 0
2021.01.19 10:20:59 4: Received data from 192.168.0.11
2021.01.19 10:20:59 4: 192.168.0.11: in cache, devices=Waschmaschine (size=1)
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHPLG2-1#2F52D8#2, validity=3840, serial=1327
2021.01.19 10:20:59 5: Found device Waschmaschine, model shellyplug
2021.01.19 10:20:59 5: cfgChanged = 2
2021.01.19 10:20:59 5: output_0 = 1
2021.01.19 10:20:59 5: power_0 = 0
2021.01.19 10:20:59 5: energy_0 = 2
2021.01.19 10:20:59 5: overpower_0 = 0
2021.01.19 10:20:59 5: overpowerValue = 0
2021.01.19 10:20:59 4: Received data from 192.168.0.13
2021.01.19 10:20:59 4: 192.168.0.13 not found in cache
2021.01.19 10:20:59 2: Defined real device Salzlampe for 192.168.0.13 as model shellyplug
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHPLG-S#7AE079#2, validity=3840, serial=3746
2021.01.19 10:20:59 5: Found device Salzlampe, model shellyplug
2021.01.19 10:20:59 5: cfgChanged = 1
2021.01.19 10:20:59 5: output_0 = 0
2021.01.19 10:20:59 5: power_0 = 0
2021.01.19 10:20:59 5: energy_0 = 318
2021.01.19 10:20:59 5: overpower_0 = 0
2021.01.19 10:20:59 5: overpowerValue = 0
2021.01.19 10:20:59 5: deviceTemp = 32.1
2021.01.19 10:20:59 5: deviceTemp = 89.78
2021.01.19 10:20:59 5: overtemp = 0
2021.01.19 10:20:59 4: Received data from 192.168.0.12
2021.01.19 10:20:59 4: 192.168.0.12 not found in cache
2021.01.19 10:20:59 2: Defined real device Vitrine for 192.168.0.12 as model shellyplug
2021.01.19 10:20:59 5: URI: /cit/s, global_devid = SHPLG-S#7AE825#2, validity=3840, serial=3735
2021.01.19 10:20:59 5: Found device Vitrine, model shellyplug
2021.01.19 10:20:59 5: cfgChanged = 1
2021.01.19 10:20:59 5: output_0 = 0
2021.01.19 10:20:59 5: power_0 = 0
2021.01.19 10:20:59 5: energy_0 = 0
2021.01.19 10:20:59 5: overpower_0 = 0
2021.01.19 10:20:59 5: overpowerValue = 0
2021.01.19 10:20:59 5: deviceTemp = 30.82
2021.01.19 10:20:59 5: deviceTemp = 87.48
2021.01.19 10:20:59 5: overtemp = 0
2021.01.19 10:21:00 4: Received data from 192.168.0.66
2021.01.19 10:21:00 4: 192.168.0.66: in cache, devices=LED_Schlafzimmer (size=1)
2021.01.19 10:21:00 5: URI: /cit/s, global_devid = SHRGBW2#66130A#2, validity=3840, serial=123
2021.01.19 10:21:00 5: Found device LED_Schlafzimmer, model shellyrgbw
2021.01.19 10:21:00 5: cfgChanged = 0
2021.01.19 10:21:00 5: output_0 = 0
2021.01.19 10:21:00 5: L-red = 18
2021.01.19 10:21:00 5: L-green = 133
2021.01.19 10:21:00 5: L-blue = 106
2021.01.19 10:21:00 5: L-white = 0
2021.01.19 10:21:00 5: gain = 14
2021.01.19 10:21:00 5: power_0 = 0
2021.01.19 10:21:00 5: energy_0 = 0
2021.01.19 10:21:00 5: overpower_0 = 0
2021.01.19 10:21:00 5: input_0 = 0
2021.01.19 10:21:00 5: inputEvent_0 =
2021.01.19 10:21:00 5: inputEventCnt_0 = 0
2021.01.19 10:21:00 5: mode = color
2021.01.19 10:21:00 4: Received data from 192.168.0.70
2021.01.19 10:21:00 4: 192.168.0.70 not found in cache
2021.01.19 10:21:00 2: Defined real device Buerolicht for 192.168.0.70 as model shellydimmer
2021.01.19 10:21:00 5: URI: /cit/s, global_devid = SHDM-1#420085#2, validity=3840, serial=2627
2021.01.19 10:21:00 5: Found device Buerolicht, model shellydimmer
2021.01.19 10:21:00 5: cfgChanged = 4
2021.01.19 10:21:00 5: output_0 = 0
2021.01.19 10:21:00 5: brightness_0 = 100
2021.01.19 10:21:00 5: input_0 = 0
2021.01.19 10:21:00 5: inputEvent_0 = S
2021.01.19 10:21:00 5: inputEventCnt_0 = 21
2021.01.19 10:21:00 5: input_1 = 0
2021.01.19 10:21:00 5: inputEvent_1 =
2021.01.19 10:21:00 5: inputEventCnt_1 = 0
2021.01.19 10:21:00 5: power_0 = 0
2021.01.19 10:21:00 5: energy_0 = 3218
2021.01.19 10:21:00 5: overpower_0 = 0
2021.01.19 10:21:00 5: overpowerValue = 0
2021.01.19 10:21:00 5: loadError = 0
2021.01.19 10:21:00 5: deviceTemp = 49.39
2021.01.19 10:21:00 5: deviceTemp = 120.9
2021.01.19 10:21:00 5: overtemp = 0
2021.01.19 10:21:00 5: mode = white
2021.01.19 10:21:00 4: Received data from 192.168.0.26
2021.01.19 10:21:00 4: 192.168.0.26 not found in cache
2021.01.19 10:21:00 2: Defined real device MarcelsBrunnen for 192.168.0.26 as model shellyplug
2021.01.19 10:21:00 5: URI: /cit/s, global_devid = SHPLG-S#7AF180#2, validity=3840, serial=3737
2021.01.19 10:21:00 5: Found device MarcelsBrunnen, model shellyplug
2021.01.19 10:21:00 5: cfgChanged = 2
2021.01.19 10:21:00 5: output_0 = 0
2021.01.19 10:21:00 5: power_0 = 0
2021.01.19 10:21:00 5: energy_0 = 0
2021.01.19 10:21:00 5: overpower_0 = 0
2021.01.19 10:21:00 5: overpowerValue = 0
2021.01.19 10:21:00 5: deviceTemp = 32.48
2021.01.19 10:21:00 5: deviceTemp = 90.47
2021.01.19 10:21:00 5: overtemp = 0
2021.01.19 10:21:02 4: Received data from 192.168.0.31
2021.01.19 10:21:02 4: 192.168.0.31 not found in cache
2021.01.19 10:21:02 2: Defined real device steinlo for 192.168.0.31 as model shelly2.5
2021.01.19 10:21:02 2: Defined real device steinlu for 192.168.0.31 as model shelly2.5
2021.01.19 10:21:02 5: URI: /cit/s, global_devid = SHSW-25#74495A#2, validity=3840, serial=3724
2021.01.19 10:21:02 5: Found device steinlo, model shelly2.5
2021.01.19 10:21:02 5: Found device steinlu, model shelly2.5
2021.01.19 10:21:02 5: cfgChanged = 1
2021.01.19 10:21:02 5: output_0 = 0
2021.01.19 10:21:02 5: output_1 = 0
2021.01.19 10:21:02 5: input_0 = 0
2021.01.19 10:21:02 5: inputEvent_0 =
2021.01.19 10:21:02 5: inputEventCnt_0 = 0
2021.01.19 10:21:02 5: input_1 = 0
2021.01.19 10:21:02 5: inputEvent_1 =
2021.01.19 10:21:02 5: inputEventCnt_1 = 0
2021.01.19 10:21:02 5: power_0 = 0
2021.01.19 10:21:02 5: energy_0 = 0
2021.01.19 10:21:02 5: overpower_0 = 0
2021.01.19 10:21:02 5: power_1 = 0
2021.01.19 10:21:02 5: energy_1 = 0
2021.01.19 10:21:02 5: overpower_1 = 0
2021.01.19 10:21:02 5: deviceTemp = 31.44
2021.01.19 10:21:02 5: overtemp = 0
2021.01.19 10:21:02 5: mode = relay
2021.01.19 10:21:02 4: Received data from 192.168.0.20
2021.01.19 10:21:02 4: 192.168.0.20: in cache, devices=Kuechenlicht (size=1)
2021.01.19 10:21:02 5: URI: /cit/s, global_devid = SHSW-1#1D9536#2, validity=3840, serial=8
2021.01.19 10:21:02 5: Found device Kuechenlicht, model shelly1
2021.01.19 10:21:02 5: cfgChanged = 1
2021.01.19 10:21:02 5: output_0 = 0
2021.01.19 10:21:02 5: input_0 = 0
2021.01.19 10:21:02 5: inputEvent_0 =
2021.01.19 10:21:02 5: inputEventCnt_0 = 0
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.12 did contain a none-hash
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.13 did contain a none-hash
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.14 did contain a none-hash
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.26 did contain a none-hash
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.31 did contain a none-hash
2021.01.19 10:21:03 1: Panic, it happened: Cache for 192.168.0.70 did contain a none-hash
2021.01.19 10:21:03 4: Received data from 192.168.0.32
2021.01.19 10:21:03 4: 192.168.0.32 not found in cache
2021.01.19 10:21:03 2: Defined real device steinro for 192.168.0.32 as model shelly2.5
2021.01.19 10:21:03 2: Defined real device steinru for 192.168.0.32 as model shelly2.5
2021.01.19 10:21:03 5: URI: /cit/s, global_devid = SHSW-25#5DBE9F#2, validity=3840, serial=3724
2021.01.19 10:21:03 5: Found device steinro, model shelly2.5
2021.01.19 10:21:03 5: Found device steinru, model shelly2.5
2021.01.19 10:21:03 5: cfgChanged = 1
2021.01.19 10:21:03 5: output_0 = 0
2021.01.19 10:21:03 5: output_1 = 0
2021.01.19 10:21:03 5: input_0 = 0
2021.01.19 10:21:03 5: inputEvent_0 =
2021.01.19 10:21:03 5: inputEventCnt_0 = 0
2021.01.19 10:21:03 5: input_1 = 0
2021.01.19 10:21:03 5: inputEvent_1 =
2021.01.19 10:21:03 5: inputEventCnt_1 = 0
2021.01.19 10:21:03 5: power_0 = 0
2021.01.19 10:21:03 5: energy_0 = 0
2021.01.19 10:21:03 5: overpower_0 = 0
2021.01.19 10:21:03 5: power_1 = 0
2021.01.19 10:21:03 5: energy_1 = 0
2021.01.19 10:21:03 5: overpower_1 = 0
2021.01.19 10:21:03 5: deviceTemp = 32.44
2021.01.19 10:21:03 5: overtemp = 0
2021.01.19 10:21:03 5: mode = relay
2021.01.19 10:21:03 4: Received data from 192.168.0.30
2021.01.19 10:21:03 4: 192.168.0.30: in cache, devices=brunnen (size=1)
2021.01.19 10:21:03 5: URI: /cit/s, global_devid = SHSW-1#50053B#2, validity=3840, serial=2
2021.01.19 10:21:03 5: Found device brunnen, model shelly1
2021.01.19 10:21:03 5: cfgChanged = 1
2021.01.19 10:21:03 5: output_0 = 0
2021.01.19 10:21:03 5: input_0 = 1
2021.01.19 10:21:03 5: inputEvent_0 = L
2021.01.19 10:21:03 5: inputEventCnt_0 = 1
2021.01.19 10:21:05 4: Received data from 192.168.0.21
2021.01.19 10:21:05 4: 192.168.0.21: in cache, devices=GaesteWC (size=1)
2021.01.19 10:21:05 5: URI: /cit/s, global_devid = SHSW-1#500284#2, validity=3840, serial=55
2021.01.19 10:21:05 5: Found device GaesteWC, model shelly1
2021.01.19 10:21:05 5: cfgChanged = 1
2021.01.19 10:21:05 5: output_0 = 0
2021.01.19 10:21:05 5: input_0 = 0
2021.01.19 10:21:05 5: inputEvent_0 =
2021.01.19 10:21:05 5: inputEventCnt_0 = 0
2021.01.19 10:21:05 4: Received data from 192.168.0.24
2021.01.19 10:21:05 4: 192.168.0.24: in cache, devices=Kugellampe (size=1)
2021.01.19 10:21:05 5: URI: /cit/s, global_devid = SHSW-1#59E51D#2, validity=3840, serial=17
2021.01.19 10:21:05 5: Found device Kugellampe, model shelly1
2021.01.19 10:21:05 5: cfgChanged = 1
2021.01.19 10:21:05 5: output_0 = 0
2021.01.19 10:21:05 5: input_0 = 0
2021.01.19 10:21:05 5: inputEvent_0 = S
2021.01.19 10:21:05 5: inputEventCnt_0 = 9
2021.01.19 10:21:06 4: Received data from 192.168.0.40
2021.01.19 10:21:06 4: 192.168.0.40: in cache, devices=Porzellanlampe (size=1)
2021.01.19 10:21:06 5: URI: /cit/s, global_devid = SHSW-1#93B01E#2, validity=3840, serial=7
2021.01.19 10:21:06 5: Found device Porzellanlampe, model shelly1
2021.01.19 10:21:06 5: cfgChanged = 1
2021.01.19 10:21:06 5: output_0 = 0
2021.01.19 10:21:06 5: input_0 = 0
2021.01.19 10:21:06 5: inputEvent_0 =
2021.01.19 10:21:06 5: inputEventCnt_0 = 0
2021.01.19 10:21:06 4: Received data from 192.168.0.35
2021.01.19 10:21:06 4: 192.168.0.35 not found in cache
2021.01.19 10:21:06 2: Defined real device steinr for 192.168.0.35 as model shelly1pm
2021.01.19 10:21:06 5: URI: /cit/s, global_devid = SHSW-PM#68C63AFB701A#2, validity=3840, serial=3724
2021.01.19 10:21:06 5: Found device steinr, model shelly1pm
2021.01.19 10:21:06 5: cfgChanged = 1
2021.01.19 10:21:06 5: output_0 = 1
2021.01.19 10:21:06 5: input_0 = 0
2021.01.19 10:21:06 5: inputEvent_0 =
2021.01.19 10:21:06 5: inputEventCnt_0 = 0
2021.01.19 10:21:06 5: power_0 = 0
2021.01.19 10:21:06 5: energy_0 = 0
2021.01.19 10:21:06 5: overpower_0 = 0
2021.01.19 10:21:06 5: overpowerValue = 0
2021.01.19 10:21:06 5: deviceTemp = 26.31
2021.01.19 10:21:06 5: deviceTemp = 79.36
2021.01.19 10:21:06 5: overtemp = 0
2021.01.19 10:21:07 4: Received data from 192.168.0.27
2021.01.19 10:21:07 4: 192.168.0.27: in cache, devices=Badlicht (size=1)
2021.01.19 10:21:07 5: URI: /cit/s, global_devid = SHSW-1#4FFF80#2, validity=3840, serial=61
2021.01.19 10:21:07 5: Found device Badlicht, model shelly1
2021.01.19 10:21:07 5: cfgChanged = 1
2021.01.19 10:21:07 5: output_0 = 0
2021.01.19 10:21:07 5: input_0 = 0
2021.01.19 10:21:07 5: inputEvent_0 =
2021.01.19 10:21:07 5: inputEventCnt_0 = 0
2021.01.19 10:21:07 1: Panic, it happened: Cache for 192.168.0.32 did contain a none-hash
2021.01.19 10:21:07 1: Panic, it happened: Cache for 192.168.0.35 did contain a none-hash
2021.01.19 10:21:09 4: Received data from 192.168.0.34
2021.01.19 10:21:09 4: 192.168.0.34 not found in cache
2021.01.19 10:21:09 2: Defined real device steinl for 192.168.0.34 as model shelly2.5
2021.01.19 10:21:09 2: Defined real device steinr2_unused for 192.168.0.34 as model shelly2.5
2021.01.19 10:21:09 5: URI: /cit/s, global_devid = SHSW-25#5DB792#2, validity=3840, serial=3723
2021.01.19 10:21:09 5: Found device steinl, model shelly2.5
2021.01.19 10:21:09 5: Found device steinr2_unused, model shelly2.5
2021.01.19 10:21:09 5: cfgChanged = 1
2021.01.19 10:21:09 5: output_0 = 0
2021.01.19 10:21:09 5: output_1 = 0
2021.01.19 10:21:09 5: input_0 = 0
2021.01.19 10:21:09 5: inputEvent_0 =
2021.01.19 10:21:09 5: inputEventCnt_0 = 0
2021.01.19 10:21:09 5: input_1 = 0
2021.01.19 10:21:09 5: inputEvent_1 =
2021.01.19 10:21:09 5: inputEventCnt_1 = 0
2021.01.19 10:21:09 5: power_0 = 0
2021.01.19 10:21:09 5: energy_0 = 0
2021.01.19 10:21:09 5: overpower_0 = 0
2021.01.19 10:21:09 5: power_1 = 0
2021.01.19 10:21:09 5: energy_1 = 0
2021.01.19 10:21:09 5: overpower_1 = 0
2021.01.19 10:21:09 5: deviceTemp = 36.38
2021.01.19 10:21:09 5: overtemp = 0
2021.01.19 10:21:09 5: mode = relay
2021.01.19 10:21:10 1: Panic, it happened: Cache for 192.168.0.34 did contain a none-hash
2021.01.19 10:21:10 4: Received data from 192.168.0.23
2021.01.19 10:21:10 4: 192.168.0.23: in cache, devices=Flur (size=1)
2021.01.19 10:21:10 5: URI: /cit/s, global_devid = SHSW-1#5006E7#2, validity=3840, serial=23
2021.01.19 10:21:10 5: Found device Flur, model shelly1
2021.01.19 10:21:10 5: cfgChanged = 4
2021.01.19 10:21:10 5: output_0 = 0
2021.01.19 10:21:10 5: input_0 = 1
2021.01.19 10:21:10 5: inputEvent_0 =
2021.01.19 10:21:10 5: inputEventCnt_0 = 0
2021.01.19 10:21:11 4: Received data from 192.168.0.29
2021.01.19 10:21:11 4: 192.168.0.29: in cache, devices=dachlicht (size=1)
2021.01.19 10:21:11 5: URI: /cit/s, global_devid = SHSW-1#1D99DC#2, validity=3840, serial=4
2021.01.19 10:21:11 5: Found device dachlicht, model shelly1
2021.01.19 10:21:11 5: cfgChanged = 1
2021.01.19 10:21:11 5: output_0 = 0
2021.01.19 10:21:11 5: input_0 = 0
2021.01.19 10:21:11 5: inputEvent_0 =
2021.01.19 10:21:11 5: inputEventCnt_0 = 0
2021.01.19 10:21:11 4: Received data from 192.168.0.28
2021.01.19 10:21:11 4: 192.168.0.28: in cache, devices=Schlafzimmer (size=1)
2021.01.19 10:21:11 5: URI: /cit/s, global_devid = SHSW-1#500DC0#2, validity=3840, serial=14
2021.01.19 10:21:11 5: Found device Schlafzimmer, model shelly1
2021.01.19 10:21:11 5: cfgChanged = 1
2021.01.19 10:21:11 5: output_0 = 0
2021.01.19 10:21:11 5: input_0 = 0
2021.01.19 10:21:11 5: inputEvent_0 =
2021.01.19 10:21:11 5: inputEventCnt_0 = 0
2021.01.19 10:21:13 4: Received data from 192.168.0.22
2021.01.19 10:21:13 4: 192.168.0.22 not found in cache
2021.01.19 10:21:13 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 10:21:13 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 10:21:13 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8545
2021.01.19 10:21:13 5: Found device Couch, model shelly2
2021.01.19 10:21:13 5: Found device Esstisch, model shelly2
2021.01.19 10:21:13 5: cfgChanged = 0
2021.01.19 10:21:13 5: output_0 = 0
2021.01.19 10:21:13 5: output_1 = 0
2021.01.19 10:21:13 5: input_0 = 0
2021.01.19 10:21:13 5: inputEvent_0 =
2021.01.19 10:21:13 5: inputEventCnt_0 = 0
2021.01.19 10:21:13 5: input_1 = 0
2021.01.19 10:21:13 5: inputEvent_1 =
2021.01.19 10:21:13 5: inputEventCnt_1 = 0
2021.01.19 10:21:13 5: power_0 = 0
2021.01.19 10:21:13 5: energy_0 = 10297
2021.01.19 10:21:13 5: overpowerValue = 0
2021.01.19 10:21:13 5: overpower_0 = 0
2021.01.19 10:21:13 5: overpower_1 = 0
2021.01.19 10:21:13 5: mode = relay
2021.01.19 10:21:14 4: Received data from 192.168.0.50
2021.01.19 10:21:14 4: 192.168.0.50: in cache, devices=LichtTreppeE_1 (size=1)
2021.01.19 10:21:14 5: URI: /cit/s, global_devid = SHSW-1#1D97D9#2, validity=3840, serial=24
2021.01.19 10:21:14 5: Found device LichtTreppeE_1, model shelly1
2021.01.19 10:21:14 5: cfgChanged = 1
2021.01.19 10:21:14 5: output_0 = 0
2021.01.19 10:21:14 5: input_0 = 1
2021.01.19 10:21:14 5: inputEvent_0 =
2021.01.19 10:21:14 5: inputEventCnt_0 = 0
2021.01.19 10:21:14 4: Received data from 192.168.0.115
2021.01.19 10:21:14 4: 192.168.0.115: in cache, devices=Trockner_16A (size=1)
2021.01.19 10:21:14 5: URI: /cit/s, global_devid = SHPLG2-1#2F562B#2, validity=3840, serial=3735
2021.01.19 10:21:14 5: Found device Trockner_16A, model shellyplug
2021.01.19 10:21:14 5: cfgChanged = 2
2021.01.19 10:21:14 5: output_0 = 1
2021.01.19 10:21:14 5: power_0 = 0
2021.01.19 10:21:14 5: energy_0 = 0
2021.01.19 10:21:14 5: overpower_0 = 0
2021.01.19 10:21:14 5: overpowerValue = 0
2021.01.19 10:21:14 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 10:21:14 4: Received data from 192.168.0.51
2021.01.19 10:21:14 4: 192.168.0.51: in cache, devices=LichtTreppe1_2 (size=1)
2021.01.19 10:21:14 5: URI: /cit/s, global_devid = SHSW-1#1D908C#2, validity=3840, serial=8
2021.01.19 10:21:14 5: Found device LichtTreppe1_2, model shelly1
2021.01.19 10:21:14 5: cfgChanged = 1
2021.01.19 10:21:14 5: output_0 = 0
2021.01.19 10:21:14 5: input_0 = 0
2021.01.19 10:21:14 5: inputEvent_0 =
2021.01.19 10:21:14 5: inputEventCnt_0 = 0
2021.01.19 10:21:14 4: Received data from 192.168.0.14
2021.01.19 10:21:14 4: 192.168.0.14 not found in cache
2021.01.19 10:21:14 2: Defined real device Spuelmaschine for 192.168.0.14 as model shellyplug
2021.01.19 10:21:14 5: URI: /cit/s, global_devid = SHPLG-S#3CF173#2, validity=3840, serial=4098
2021.01.19 10:21:14 5: Found device Spuelmaschine, model shellyplug
2021.01.19 10:21:14 5: cfgChanged = 1
2021.01.19 10:21:14 5: output_0 = 1
2021.01.19 10:21:14 5: power_0 = 0.69
2021.01.19 10:21:14 5: energy_0 = 178916
2021.01.19 10:21:14 5: overpower_0 = 0
2021.01.19 10:21:14 5: overpowerValue = 0
2021.01.19 10:21:14 5: deviceTemp = 28.08
2021.01.19 10:21:14 5: deviceTemp = 82.54
2021.01.19 10:21:14 5: overtemp = 0
2021.01.19 10:21:15 4: Received data from 192.168.0.11
2021.01.19 10:21:15 4: 192.168.0.11: in cache, devices=Waschmaschine (size=1)
2021.01.19 10:21:15 5: URI: /cit/s, global_devid = SHPLG2-1#2F52D8#2, validity=3840, serial=1327
2021.01.19 10:21:15 5: Found device Waschmaschine, model shellyplug
2021.01.19 10:21:15 5: cfgChanged = 2
2021.01.19 10:21:15 5: output_0 = 1
2021.01.19 10:21:15 5: power_0 = 0
2021.01.19 10:21:15 5: energy_0 = 2
2021.01.19 10:21:15 5: overpower_0 = 0
2021.01.19 10:21:15 5: overpowerValue = 0
2021.01.19 10:21:15 4: Received data from 192.168.0.12
2021.01.19 10:21:15 4: 192.168.0.12 not found in cache
2021.01.19 10:21:15 2: Defined real device Vitrine for 192.168.0.12 as model shellyplug
2021.01.19 10:21:15 5: URI: /cit/s, global_devid = SHPLG-S#7AE825#2, validity=3840, serial=3735
2021.01.19 10:21:15 5: Found device Vitrine, model shellyplug
2021.01.19 10:21:15 5: cfgChanged = 1
2021.01.19 10:21:15 5: output_0 = 0
2021.01.19 10:21:15 5: power_0 = 0
2021.01.19 10:21:15 5: energy_0 = 0
2021.01.19 10:21:15 5: overpower_0 = 0
2021.01.19 10:21:15 5: overpowerValue = 0
2021.01.19 10:21:15 5: deviceTemp = 30.77
2021.01.19 10:21:15 5: deviceTemp = 87.38
2021.01.19 10:21:15 5: overtemp = 0
2021.01.19 10:21:15 4: Received data from 192.168.0.13
2021.01.19 10:21:15 4: 192.168.0.13 not found in cache
2021.01.19 10:21:15 2: Defined real device Salzlampe for 192.168.0.13 as model shellyplug
2021.01.19 10:21:15 5: URI: /cit/s, global_devid = SHPLG-S#7AE079#2, validity=3840, serial=3746
2021.01.19 10:21:15 5: Found device Salzlampe, model shellyplug
2021.01.19 10:21:15 5: cfgChanged = 1
2021.01.19 10:21:15 5: output_0 = 0
2021.01.19 10:21:15 5: power_0 = 0
2021.01.19 10:21:15 5: energy_0 = 318
2021.01.19 10:21:15 5: overpower_0 = 0
2021.01.19 10:21:15 5: overpowerValue = 0
2021.01.19 10:21:15 5: deviceTemp = 32.04
2021.01.19 10:21:15 5: deviceTemp = 89.68
2021.01.19 10:21:15 5: overtemp = 0
2021.01.19 10:21:15 4: Received data from 192.168.0.66
2021.01.19 10:21:15 4: 192.168.0.66: in cache, devices=LED_Schlafzimmer (size=1)
2021.01.19 10:21:15 5: URI: /cit/s, global_devid = SHRGBW2#66130A#2, validity=3840, serial=123
2021.01.19 10:21:15 5: Found device LED_Schlafzimmer, model shellyrgbw
2021.01.19 10:21:15 5: cfgChanged = 0
2021.01.19 10:21:15 5: output_0 = 0
2021.01.19 10:21:15 5: L-red = 18
2021.01.19 10:21:15 5: L-green = 133
2021.01.19 10:21:15 5: L-blue = 106
2021.01.19 10:21:15 5: L-white = 0
2021.01.19 10:21:15 5: gain = 14
2021.01.19 10:21:15 5: power_0 = 0
2021.01.19 10:21:15 5: energy_0 = 0
2021.01.19 10:21:15 5: overpower_0 = 0
2021.01.19 10:21:15 5: input_0 = 0
2021.01.19 10:21:15 5: inputEvent_0 =
2021.01.19 10:21:15 5: inputEventCnt_0 = 0
2021.01.19 10:21:15 5: mode = color
2021.01.19 10:21:15 4: Received data from 192.168.0.70
2021.01.19 10:21:15 4: 192.168.0.70 not found in cache
2021.01.19 10:21:15 2: Defined real device Buerolicht for 192.168.0.70 as model shellydimmer
2021.01.19 10:21:15 5: URI: /cit/s, global_devid = SHDM-1#420085#2, validity=3840, serial=2627
2021.01.19 10:21:15 5: Found device Buerolicht, model shellydimmer
2021.01.19 10:21:15 5: cfgChanged = 4
2021.01.19 10:21:15 5: output_0 = 0
2021.01.19 10:21:15 5: brightness_0 = 100
2021.01.19 10:21:15 5: input_0 = 0
2021.01.19 10:21:15 5: inputEvent_0 = S
2021.01.19 10:21:15 5: inputEventCnt_0 = 21
2021.01.19 10:21:15 5: input_1 = 0
2021.01.19 10:21:15 5: inputEvent_1 =
2021.01.19 10:21:16 5: inputEventCnt_1 = 0
2021.01.19 10:21:16 5: power_0 = 0
2021.01.19 10:21:16 5: energy_0 = 3218
2021.01.19 10:21:16 5: overpower_0 = 0
2021.01.19 10:21:16 5: overpowerValue = 0
2021.01.19 10:21:16 5: loadError = 0
2021.01.19 10:21:16 5: deviceTemp = 49.39
2021.01.19 10:21:16 5: deviceTemp = 120.9
2021.01.19 10:21:16 5: overtemp = 0
2021.01.19 10:21:16 5: mode = white
2021.01.19 10:21:16 4: Received data from 192.168.0.26
2021.01.19 10:21:16 4: 192.168.0.26 not found in cache
2021.01.19 10:21:16 2: Defined real device MarcelsBrunnen for 192.168.0.26 as model shellyplug
2021.01.19 10:21:16 5: URI: /cit/s, global_devid = SHPLG-S#7AF180#2, validity=3840, serial=3737
2021.01.19 10:21:16 5: Found device MarcelsBrunnen, model shellyplug
2021.01.19 10:21:16 5: cfgChanged = 2
2021.01.19 10:21:16 5: output_0 = 0
2021.01.19 10:21:16 5: power_0 = 0
2021.01.19 10:21:16 5: energy_0 = 0
2021.01.19 10:21:16 5: overpower_0 = 0
2021.01.19 10:21:16 5: overpowerValue = 0
2021.01.19 10:21:16 5: deviceTemp = 32.48
2021.01.19 10:21:16 5: deviceTemp = 90.47
2021.01.19 10:21:16 5: overtemp = 0
2021.01.19 10:21:16 4: Received data from 192.168.0.34
2021.01.19 10:21:16 4: 192.168.0.34 not found in cache
2021.01.19 10:21:16 2: Defined real device steinl for 192.168.0.34 as model shelly2.5
2021.01.19 10:21:16 2: Defined real device steinr2_unused for 192.168.0.34 as model shelly2.5
2021.01.19 10:21:16 5: URI: /cit/s, global_devid = SHSW-25#5DB792#2, validity=3840, serial=3724
2021.01.19 10:21:16 5: Found device steinl, model shelly2.5
2021.01.19 10:21:16 5: Found device steinr2_unused, model shelly2.5
2021.01.19 10:21:16 5: cfgChanged = 1
2021.01.19 10:21:16 5: output_0 = 0
2021.01.19 10:21:16 5: output_1 = 0
2021.01.19 10:21:16 5: input_0 = 0
2021.01.19 10:21:16 5: inputEvent_0 =
2021.01.19 10:21:16 5: inputEventCnt_0 = 0
2021.01.19 10:21:16 5: input_1 = 0
2021.01.19 10:21:16 5: inputEvent_1 =
2021.01.19 10:21:16 5: inputEventCnt_1 = 0
2021.01.19 10:21:16 5: power_0 = 0
2021.01.19 10:21:16 5: energy_0 = 0
2021.01.19 10:21:16 5: overpower_0 = 0
2021.01.19 10:21:16 5: power_1 = 0
2021.01.19 10:21:16 5: energy_1 = 0
2021.01.19 10:21:16 5: overpower_1 = 0
2021.01.19 10:21:16 5: deviceTemp = 36.32
2021.01.19 10:21:16 5: overtemp = 0
2021.01.19 10:21:16 5: mode = relay
2021.01.19 10:21:17 4: Received data from 192.168.0.31
2021.01.19 10:21:17 4: 192.168.0.31 not found in cache
2021.01.19 10:21:17 2: Defined real device steinlo for 192.168.0.31 as model shelly2.5
2021.01.19 10:21:17 2: Defined real device steinlu for 192.168.0.31 as model shelly2.5
2021.01.19 10:21:17 5: URI: /cit/s, global_devid = SHSW-25#74495A#2, validity=3840, serial=3724
2021.01.19 10:21:17 5: Found device steinlo, model shelly2.5
2021.01.19 10:21:17 5: Found device steinlu, model shelly2.5
2021.01.19 10:21:17 5: cfgChanged = 1
2021.01.19 10:21:17 5: output_0 = 0
2021.01.19 10:21:17 5: output_1 = 0
2021.01.19 10:21:17 5: input_0 = 0
2021.01.19 10:21:17 5: inputEvent_0 =
2021.01.19 10:21:17 5: inputEventCnt_0 = 0
2021.01.19 10:21:17 5: input_1 = 0
2021.01.19 10:21:17 5: inputEvent_1 =
2021.01.19 10:21:17 5: inputEventCnt_1 = 0
2021.01.19 10:21:17 5: power_0 = 0
2021.01.19 10:21:17 5: energy_0 = 0
2021.01.19 10:21:17 5: overpower_0 = 0
2021.01.19 10:21:17 5: power_1 = 0
2021.01.19 10:21:17 5: energy_1 = 0
2021.01.19 10:21:17 5: overpower_1 = 0
2021.01.19 10:21:17 5: deviceTemp = 31.44
2021.01.19 10:21:17 5: overtemp = 0
2021.01.19 10:21:17 5: mode = relay
2021.01.19 10:21:17 4: Received data from 192.168.0.20
2021.01.19 10:21:17 4: 192.168.0.20: in cache, devices=Kuechenlicht (size=1)
2021.01.19 10:21:17 5: URI: /cit/s, global_devid = SHSW-1#1D9536#2, validity=3840, serial=8
2021.01.19 10:21:17 5: Found device Kuechenlicht, model shelly1
2021.01.19 10:21:17 5: cfgChanged = 1
2021.01.19 10:21:17 5: output_0 = 0
2021.01.19 10:21:17 5: input_0 = 0
2021.01.19 10:21:17 5: inputEvent_0 =
2021.01.19 10:21:17 5: inputEventCnt_0 = 0
2021.01.19 10:21:18 4: Received data from 192.168.0.32
2021.01.19 10:21:18 4: 192.168.0.32 not found in cache
2021.01.19 10:21:18 2: Defined real device steinro for 192.168.0.32 as model shelly2.5
2021.01.19 10:21:18 2: Defined real device steinru for 192.168.0.32 as model shelly2.5
2021.01.19 10:21:18 5: URI: /cit/s, global_devid = SHSW-25#5DBE9F#2, validity=3840, serial=3724
2021.01.19 10:21:18 5: Found device steinro, model shelly2.5
2021.01.19 10:21:18 5: Found device steinru, model shelly2.5
2021.01.19 10:21:18 5: cfgChanged = 1
2021.01.19 10:21:18 5: output_0 = 0
2021.01.19 10:21:18 5: output_1 = 0
2021.01.19 10:21:18 5: input_0 = 0
2021.01.19 10:21:18 5: inputEvent_0 =
2021.01.19 10:21:18 5: inputEventCnt_0 = 0
2021.01.19 10:21:18 5: input_1 = 0
2021.01.19 10:21:18 5: inputEvent_1 =
2021.01.19 10:21:18 5: inputEventCnt_1 = 0
2021.01.19 10:21:18 5: power_0 = 0
2021.01.19 10:21:18 5: energy_0 = 0
2021.01.19 10:21:18 5: overpower_0 = 0
2021.01.19 10:21:18 5: power_1 = 0
2021.01.19 10:21:18 5: energy_1 = 0
2021.01.19 10:21:18 5: overpower_1 = 0
2021.01.19 10:21:18 5: deviceTemp = 32.44
2021.01.19 10:21:18 5: overtemp = 0
2021.01.19 10:21:18 5: mode = relay
2021.01.19 10:21:19 4: Received data from 192.168.0.30
2021.01.19 10:21:19 4: 192.168.0.30: in cache, devices=brunnen (size=1)
2021.01.19 10:21:19 5: URI: /cit/s, global_devid = SHSW-1#50053B#2, validity=3840, serial=2
2021.01.19 10:21:19 5: Found device brunnen, model shelly1
2021.01.19 10:21:19 5: cfgChanged = 1
2021.01.19 10:21:19 5: output_0 = 0
2021.01.19 10:21:19 5: input_0 = 1
2021.01.19 10:21:19 5: inputEvent_0 = L
2021.01.19 10:21:19 5: inputEventCnt_0 = 1
2021.01.19 10:21:19 4: Received data from 192.168.0.22
2021.01.19 10:21:19 4: 192.168.0.22 not found in cache
2021.01.19 10:21:19 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 10:21:19 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 10:21:19 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8546
2021.01.19 10:21:19 5: Found device Couch, model shelly2
2021.01.19 10:21:19 5: Found device Esstisch, model shelly2
2021.01.19 10:21:19 5: cfgChanged = 0
2021.01.19 10:21:19 5: output_0 = 0
2021.01.19 10:21:19 5: output_1 = 0
2021.01.19 10:21:19 5: input_0 = 0
2021.01.19 10:21:19 5: inputEvent_0 =
2021.01.19 10:21:19 5: inputEventCnt_0 = 0
2021.01.19 10:21:19 5: input_1 = 0
2021.01.19 10:21:19 5: inputEvent_1 =
2021.01.19 10:21:19 5: inputEventCnt_1 = 0
2021.01.19 10:21:19 5: power_0 = 0
2021.01.19 10:21:19 5: energy_0 = 10297
2021.01.19 10:21:19 5: overpowerValue = 0
2021.01.19 10:21:19 5: overpower_0 = 0
2021.01.19 10:21:19 5: overpower_1 = 0
2021.01.19 10:21:19 5: mode = relay
2021.01.19 10:21:21 4: Received data from 192.168.0.24
2021.01.19 10:21:21 4: 192.168.0.24: in cache, devices=Kugellampe (size=1)
2021.01.19 10:21:21 5: URI: /cit/s, global_devid = SHSW-1#59E51D#2, validity=3840, serial=17
2021.01.19 10:21:21 5: Found device Kugellampe, model shelly1
2021.01.19 10:21:21 5: cfgChanged = 1
2021.01.19 10:21:21 5: output_0 = 0
2021.01.19 10:21:21 5: input_0 = 0
2021.01.19 10:21:21 5: inputEvent_0 = S
2021.01.19 10:21:21 5: inputEventCnt_0 = 9
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.12 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.13 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.14 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.26 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.31 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.32 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.34 did contain a none-hash
2021.01.19 10:21:21 1: Panic, it happened: Cache for 192.168.0.70 did contain a none-hash



ist nur ca. eine halbe Minute, aber sonst schluckt es das Forum nicht korrekt.
Sollte aber aus meiner Sicht reichen

Kannst Du mir den Gefallen tun, mal die angehängte Version auszuprobieren?
These eines Ahnungsarmen: In den aufgerufenen externen Funktionen wird der Wert von @device verändert, weil der Scope von Variablen nicht wie bei C oder Java nur funktionsintern ist. Test: "devices" in "devrefs" umbenannt.

Zitat von: gvzdus am 19 Januar 2021, 10:57:01
Kannst Du mir den Gefallen tun, mal die angehängte Version auszuprobieren?
These eines Ahnungsarmen: In den aufgerufenen externen Funktionen wird der Wert von @device verändert, weil der Scope von Variablen nicht wie bei C oder Java nur funktionsintern ist. Test: "devices" in "devrefs" umbenannt.

2021.01.19 11:22:59 4: Received data from 192.168.0.11
2021.01.19 11:22:59 4: 192.168.0.11: in cache, devices=Waschmaschine (size=1)
2021.01.19 11:22:59 5: URI: /cit/s, global_devid = SHPLG2-1#2F52D8#2, validity=3840, serial=1389
2021.01.19 11:22:59 5: Found device Waschmaschine, model shellyplug
2021.01.19 11:22:59 5: cfgChanged = 2
2021.01.19 11:22:59 5: output_0 = 1
2021.01.19 11:22:59 5: power_0 = 0
2021.01.19 11:22:59 5: energy_0 = 2
2021.01.19 11:22:59 5: overpower_0 = 0
2021.01.19 11:22:59 5: overpowerValue = 0
2021.01.19 11:22:59 4: Received data from 192.168.0.12
2021.01.19 11:22:59 4: 192.168.0.12: in cache, devices=Vitrine (size=1)
2021.01.19 11:22:59 5: URI: /cit/s, global_devid = SHPLG-S#7AE825#2, validity=3840, serial=3797
2021.01.19 11:22:59 5: Found device Vitrine, model shellyplug
2021.01.19 11:22:59 5: cfgChanged = 1
2021.01.19 11:22:59 5: output_0 = 0
2021.01.19 11:22:59 5: power_0 = 0
2021.01.19 11:22:59 5: energy_0 = 0
2021.01.19 11:22:59 5: overpower_0 = 0
2021.01.19 11:22:59 5: overpowerValue = 0
2021.01.19 11:22:59 5: deviceTemp = 31.32
2021.01.19 11:22:59 5: deviceTemp = 88.38
2021.01.19 11:22:59 5: overtemp = 0
2021.01.19 11:23:00 4: Received data from 192.168.0.14
2021.01.19 11:23:00 4: 192.168.0.14 not found in cache
2021.01.19 11:23:00 2: Defined real device Spuelmaschine for 192.168.0.14 as model shellyplug
2021.01.19 11:23:00 5: URI: /cit/s, global_devid = SHPLG-S#3CF173#2, validity=3840, serial=4160
2021.01.19 11:23:00 5: Found device Spuelmaschine, model shellyplug
2021.01.19 11:23:00 5: cfgChanged = 1
2021.01.19 11:23:00 5: output_0 = 1
2021.01.19 11:23:00 5: power_0 = 0
2021.01.19 11:23:00 5: energy_0 = 178937
2021.01.19 11:23:00 5: overpower_0 = 0
2021.01.19 11:23:00 5: overpowerValue = 0
2021.01.19 11:23:00 5: deviceTemp = 28.14
2021.01.19 11:23:00 5: deviceTemp = 82.65
2021.01.19 11:23:00 5: overtemp = 0
2021.01.19 11:23:00 4: Received data from 192.168.0.13
2021.01.19 11:23:00 4: 192.168.0.13 not found in cache
2021.01.19 11:23:00 2: Defined real device Salzlampe for 192.168.0.13 as model shellyplug
2021.01.19 11:23:00 5: URI: /cit/s, global_devid = SHPLG-S#7AE079#2, validity=3840, serial=3808
2021.01.19 11:23:00 5: Found device Salzlampe, model shellyplug
2021.01.19 11:23:00 5: cfgChanged = 1
2021.01.19 11:23:00 5: output_0 = 0
2021.01.19 11:23:00 5: power_0 = 0
2021.01.19 11:23:00 5: energy_0 = 318
2021.01.19 11:23:00 5: overpower_0 = 0
2021.01.19 11:23:00 5: overpowerValue = 0
2021.01.19 11:23:00 5: deviceTemp = 32.65
2021.01.19 11:23:00 5: deviceTemp = 90.76
2021.01.19 11:23:00 5: overtemp = 0
2021.01.19 11:23:01 1: Panic, it happened: Cache for 192.168.0.13 did contain a none-hash
2021.01.19 11:23:01 1: Panic, it happened: Cache for 192.168.0.14 did contain a none-hash
2021.01.19 11:23:01 1: Panic, it happened: Cache for 192.168.0.34 did contain a none-hash
2021.01.19 11:23:01 1: Panic, it happened: Cache for 192.168.0.35 did contain a none-hash
2021.01.19 11:23:01 4: Received data from 192.168.0.66
2021.01.19 11:23:01 4: 192.168.0.66: in cache, devices=LED_Schlafzimmer (size=1)
2021.01.19 11:23:01 5: URI: /cit/s, global_devid = SHRGBW2#66130A#2, validity=3840, serial=185
2021.01.19 11:23:01 5: Found device LED_Schlafzimmer, model shellyrgbw
2021.01.19 11:23:01 5: cfgChanged = 0
2021.01.19 11:23:01 5: output_0 = 0
2021.01.19 11:23:01 5: L-red = 18
2021.01.19 11:23:01 5: L-green = 133
2021.01.19 11:23:01 5: L-blue = 106
2021.01.19 11:23:01 5: L-white = 0
2021.01.19 11:23:01 5: gain = 14
2021.01.19 11:23:01 5: power_0 = 0
2021.01.19 11:23:01 5: energy_0 = 0
2021.01.19 11:23:01 5: overpower_0 = 0
2021.01.19 11:23:01 5: input_0 = 0
2021.01.19 11:23:01 5: inputEvent_0 =
2021.01.19 11:23:01 5: inputEventCnt_0 = 0
2021.01.19 11:23:01 5: mode = color
2021.01.19 11:23:01 4: Received data from 192.168.0.26
2021.01.19 11:23:01 4: 192.168.0.26 not found in cache
2021.01.19 11:23:01 2: Defined real device MarcelsBrunnen for 192.168.0.26 as model shellyplug
2021.01.19 11:23:01 5: URI: /cit/s, global_devid = SHPLG-S#7AF180#2, validity=3840, serial=3799
2021.01.19 11:23:01 5: Found device MarcelsBrunnen, model shellyplug
2021.01.19 11:23:01 5: cfgChanged = 2
2021.01.19 11:23:01 5: output_0 = 0
2021.01.19 11:23:01 5: power_0 = 0
2021.01.19 11:23:01 5: energy_0 = 0
2021.01.19 11:23:01 5: overpower_0 = 0
2021.01.19 11:23:01 5: overpowerValue = 0
2021.01.19 11:23:01 5: deviceTemp = 32.04
2021.01.19 11:23:01 5: deviceTemp = 89.68
2021.01.19 11:23:01 5: overtemp = 0
2021.01.19 11:23:01 4: Received data from 192.168.0.70
2021.01.19 11:23:01 4: 192.168.0.70 not found in cache
2021.01.19 11:23:01 2: Defined real device Buerolicht for 192.168.0.70 as model shellydimmer
2021.01.19 11:23:01 5: URI: /cit/s, global_devid = SHDM-1#420085#2, validity=3840, serial=2689
2021.01.19 11:23:01 5: Found device Buerolicht, model shellydimmer
2021.01.19 11:23:01 5: cfgChanged = 4
2021.01.19 11:23:01 5: output_0 = 0
2021.01.19 11:23:01 5: brightness_0 = 100
2021.01.19 11:23:01 5: input_0 = 0
2021.01.19 11:23:01 5: inputEvent_0 = S
2021.01.19 11:23:01 5: inputEventCnt_0 = 21
2021.01.19 11:23:01 5: input_1 = 0
2021.01.19 11:23:01 5: inputEvent_1 =
2021.01.19 11:23:01 5: inputEventCnt_1 = 0
2021.01.19 11:23:01 5: power_0 = 0
2021.01.19 11:23:01 5: energy_0 = 3218
2021.01.19 11:23:01 5: overpower_0 = 0
2021.01.19 11:23:01 5: overpowerValue = 0
2021.01.19 11:23:01 5: loadError = 0
2021.01.19 11:23:01 5: deviceTemp = 49.66
2021.01.19 11:23:01 5: deviceTemp = 121.39
2021.01.19 11:23:01 5: overtemp = 0
2021.01.19 11:23:01 5: mode = white
2021.01.19 11:23:01 4: Received data from 192.168.0.34
2021.01.19 11:23:01 4: 192.168.0.34 not found in cache
2021.01.19 11:23:01 2: Defined real device steinl for 192.168.0.34 as model shelly2.5
2021.01.19 11:23:01 2: Defined real device steinr2_unused for 192.168.0.34 as model shelly2.5
2021.01.19 11:23:01 5: URI: /cit/s, global_devid = SHSW-25#5DB792#2, validity=3840, serial=3786
2021.01.19 11:23:01 5: Found device steinl, model shelly2.5
2021.01.19 11:23:01 5: Found device steinr2_unused, model shelly2.5
2021.01.19 11:23:01 5: cfgChanged = 1
2021.01.19 11:23:01 5: output_0 = 0
2021.01.19 11:23:01 5: output_1 = 0
2021.01.19 11:23:01 5: input_0 = 0
2021.01.19 11:23:01 5: inputEvent_0 =
2021.01.19 11:23:01 5: inputEventCnt_0 = 0
2021.01.19 11:23:01 5: input_1 = 0
2021.01.19 11:23:01 5: inputEvent_1 =
2021.01.19 11:23:01 5: inputEventCnt_1 = 0
2021.01.19 11:23:01 5: power_0 = 0
2021.01.19 11:23:01 5: energy_0 = 0
2021.01.19 11:23:01 5: overpower_0 = 0
2021.01.19 11:23:01 5: power_1 = 0
2021.01.19 11:23:01 5: energy_1 = 0
2021.01.19 11:23:01 5: overpower_1 = 0
2021.01.19 11:23:01 5: deviceTemp = 37.16
2021.01.19 11:23:01 5: overtemp = 0
2021.01.19 11:23:01 5: mode = relay
2021.01.19 11:23:01 4: Received data from 192.168.0.31
2021.01.19 11:23:01 4: 192.168.0.31 not found in cache
2021.01.19 11:23:01 2: Defined real device steinlo for 192.168.0.31 as model shelly2.5
2021.01.19 11:23:01 2: Defined real device steinlu for 192.168.0.31 as model shelly2.5
2021.01.19 11:23:01 5: URI: /cit/s, global_devid = SHSW-25#74495A#2, validity=3840, serial=3786
2021.01.19 11:23:01 5: Found device steinlo, model shelly2.5
2021.01.19 11:23:01 5: Found device steinlu, model shelly2.5
2021.01.19 11:23:01 5: cfgChanged = 1
2021.01.19 11:23:01 5: output_0 = 0
2021.01.19 11:23:01 5: output_1 = 0
2021.01.19 11:23:01 5: input_0 = 0
2021.01.19 11:23:01 5: inputEvent_0 =
2021.01.19 11:23:01 5: inputEventCnt_0 = 0
2021.01.19 11:23:01 5: input_1 = 0
2021.01.19 11:23:01 5: inputEvent_1 =
2021.01.19 11:23:01 5: inputEventCnt_1 = 0
2021.01.19 11:23:01 5: power_0 = 0
2021.01.19 11:23:01 5: energy_0 = 0
2021.01.19 11:23:01 5: overpower_0 = 0
2021.01.19 11:23:01 5: power_1 = 0
2021.01.19 11:23:01 5: energy_1 = 0
2021.01.19 11:23:01 5: overpower_1 = 0
2021.01.19 11:23:01 5: deviceTemp = 31.65
2021.01.19 11:23:01 5: overtemp = 0
2021.01.19 11:23:01 5: mode = relay
2021.01.19 11:23:02 4: Received data from 192.168.0.30
2021.01.19 11:23:02 4: 192.168.0.30: in cache, devices=brunnen (size=1)
2021.01.19 11:23:02 5: URI: /cit/s, global_devid = SHSW-1#50053B#2, validity=3840, serial=2
2021.01.19 11:23:02 5: Found device brunnen, model shelly1
2021.01.19 11:23:02 5: cfgChanged = 1
2021.01.19 11:23:02 5: output_0 = 0
2021.01.19 11:23:02 5: input_0 = 1
2021.01.19 11:23:02 5: inputEvent_0 = L
2021.01.19 11:23:02 5: inputEventCnt_0 = 1
2021.01.19 11:23:02 4: Received data from 192.168.0.24
2021.01.19 11:23:02 4: 192.168.0.24: in cache, devices=Kugellampe (size=1)
2021.01.19 11:23:02 5: URI: /cit/s, global_devid = SHSW-1#59E51D#2, validity=3840, serial=17
2021.01.19 11:23:02 5: Found device Kugellampe, model shelly1
2021.01.19 11:23:02 5: cfgChanged = 1
2021.01.19 11:23:02 5: output_0 = 0
2021.01.19 11:23:02 5: input_0 = 0
2021.01.19 11:23:02 5: inputEvent_0 = S
2021.01.19 11:23:02 5: inputEventCnt_0 = 9
2021.01.19 11:23:03 4: Received data from 192.168.0.32
2021.01.19 11:23:03 4: 192.168.0.32 not found in cache
2021.01.19 11:23:03 2: Defined real device steinro for 192.168.0.32 as model shelly2.5
2021.01.19 11:23:03 2: Defined real device steinru for 192.168.0.32 as model shelly2.5
2021.01.19 11:23:03 5: URI: /cit/s, global_devid = SHSW-25#5DBE9F#2, validity=3840, serial=3785
2021.01.19 11:23:03 5: Found device steinro, model shelly2.5
2021.01.19 11:23:03 5: Found device steinru, model shelly2.5
2021.01.19 11:23:03 5: cfgChanged = 1
2021.01.19 11:23:03 5: output_0 = 0
2021.01.19 11:23:03 5: output_1 = 0
2021.01.19 11:23:03 5: input_0 = 0
2021.01.19 11:23:03 5: inputEvent_0 =
2021.01.19 11:23:03 5: inputEventCnt_0 = 0
2021.01.19 11:23:03 5: input_1 = 0
2021.01.19 11:23:03 5: inputEvent_1 =
2021.01.19 11:23:03 5: inputEventCnt_1 = 0
2021.01.19 11:23:03 5: power_0 = 0
2021.01.19 11:23:03 5: energy_0 = 0
2021.01.19 11:23:03 5: overpower_0 = 0
2021.01.19 11:23:03 5: power_1 = 0
2021.01.19 11:23:03 5: energy_1 = 0
2021.01.19 11:23:03 5: overpower_1 = 0
2021.01.19 11:23:03 5: deviceTemp = 32.71
2021.01.19 11:23:03 5: overtemp = 0
2021.01.19 11:23:03 5: mode = relay
2021.01.19 11:23:04 4: Received data from 192.168.0.40
2021.01.19 11:23:04 4: 192.168.0.40: in cache, devices=Porzellanlampe (size=1)
2021.01.19 11:23:04 5: URI: /cit/s, global_devid = SHSW-1#93B01E#2, validity=3840, serial=7
2021.01.19 11:23:04 5: Found device Porzellanlampe, model shelly1
2021.01.19 11:23:04 5: cfgChanged = 1
2021.01.19 11:23:04 5: output_0 = 0
2021.01.19 11:23:04 5: input_0 = 0
2021.01.19 11:23:04 5: inputEvent_0 =
2021.01.19 11:23:04 5: inputEventCnt_0 = 0
2021.01.19 11:23:04 1: Panic, it happened: Cache for 192.168.0.26 did contain a none-hash
2021.01.19 11:23:04 1: Panic, it happened: Cache for 192.168.0.31 did contain a none-hash
2021.01.19 11:23:04 1: Panic, it happened: Cache for 192.168.0.32 did contain a none-hash
2021.01.19 11:23:04 1: Panic, it happened: Cache for 192.168.0.34 did contain a none-hash
2021.01.19 11:23:04 1: Panic, it happened: Cache for 192.168.0.70 did contain a none-hash
2021.01.19 11:23:06 4: Received data from 192.168.0.23
2021.01.19 11:23:06 4: 192.168.0.23: in cache, devices=Flur (size=1)
2021.01.19 11:23:06 5: URI: /cit/s, global_devid = SHSW-1#5006E7#2, validity=3840, serial=23
2021.01.19 11:23:06 5: Found device Flur, model shelly1
2021.01.19 11:23:06 5: cfgChanged = 4
2021.01.19 11:23:06 5: output_0 = 0
2021.01.19 11:23:06 5: input_0 = 1
2021.01.19 11:23:06 5: inputEvent_0 =
2021.01.19 11:23:06 5: inputEventCnt_0 = 0
2021.01.19 11:23:06 4: Received data from 192.168.0.22
2021.01.19 11:23:06 4: 192.168.0.22 not found in cache
2021.01.19 11:23:06 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 11:23:06 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 11:23:06 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8607
2021.01.19 11:23:06 5: Found device Couch, model shelly2
2021.01.19 11:23:06 5: Found device Esstisch, model shelly2
2021.01.19 11:23:06 5: cfgChanged = 0
2021.01.19 11:23:06 5: output_0 = 0
2021.01.19 11:23:06 5: output_1 = 0
2021.01.19 11:23:06 5: input_0 = 0
2021.01.19 11:23:06 5: inputEvent_0 =
2021.01.19 11:23:06 5: inputEventCnt_0 = 0
2021.01.19 11:23:06 5: input_1 = 0
2021.01.19 11:23:06 5: inputEvent_1 =
2021.01.19 11:23:06 5: inputEventCnt_1 = 0
2021.01.19 11:23:06 5: power_0 = 0
2021.01.19 11:23:06 5: energy_0 = 10297
2021.01.19 11:23:06 5: overpowerValue = 0
2021.01.19 11:23:06 5: overpower_0 = 0
2021.01.19 11:23:06 5: overpower_1 = 0
2021.01.19 11:23:06 5: mode = relay
2021.01.19 11:23:07 4: Received data from 192.168.0.29
2021.01.19 11:23:07 4: 192.168.0.29: in cache, devices=dachlicht (size=1)
2021.01.19 11:23:07 5: URI: /cit/s, global_devid = SHSW-1#1D99DC#2, validity=3840, serial=4
2021.01.19 11:23:07 5: Found device dachlicht, model shelly1
2021.01.19 11:23:07 5: cfgChanged = 1
2021.01.19 11:23:07 5: output_0 = 0
2021.01.19 11:23:07 5: input_0 = 0
2021.01.19 11:23:07 5: inputEvent_0 =
2021.01.19 11:23:07 5: inputEventCnt_0 = 0
2021.01.19 11:23:08 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 11:23:09 4: Received data from 192.168.0.28
2021.01.19 11:23:09 4: 192.168.0.28: in cache, devices=Schlafzimmer (size=1)
2021.01.19 11:23:09 5: URI: /cit/s, global_devid = SHSW-1#500DC0#2, validity=3840, serial=14
2021.01.19 11:23:09 5: Found device Schlafzimmer, model shelly1
2021.01.19 11:23:09 5: cfgChanged = 1
2021.01.19 11:23:09 5: output_0 = 0
2021.01.19 11:23:09 5: input_0 = 0
2021.01.19 11:23:09 5: inputEvent_0 =
2021.01.19 11:23:09 5: inputEventCnt_0 = 0
2021.01.19 11:23:09 4: Received data from 192.168.0.35
2021.01.19 11:23:09 4: 192.168.0.35 not found in cache
2021.01.19 11:23:09 2: Defined real device steinr for 192.168.0.35 as model shelly1pm
2021.01.19 11:23:09 5: URI: /cit/s, global_devid = SHSW-PM#68C63AFB701A#2, validity=3840, serial=3787
2021.01.19 11:23:09 5: Found device steinr, model shelly1pm
2021.01.19 11:23:09 5: cfgChanged = 1
2021.01.19 11:23:09 5: output_0 = 1
2021.01.19 11:23:09 5: input_0 = 0
2021.01.19 11:23:09 5: inputEvent_0 =
2021.01.19 11:23:09 5: inputEventCnt_0 = 0
2021.01.19 11:23:09 5: power_0 = 0
2021.01.19 11:23:09 5: energy_0 = 0
2021.01.19 11:23:09 5: overpower_0 = 0
2021.01.19 11:23:09 5: overpowerValue = 0
2021.01.19 11:23:09 5: deviceTemp = 29.86
2021.01.19 11:23:09 5: deviceTemp = 85.75
2021.01.19 11:23:09 5: overtemp = 0
2021.01.19 11:23:09 4: Received data from 192.168.0.35
2021.01.19 11:23:09 1: Panic, it happened: Cache for 192.168.0.35 did contain a none-hash
2021.01.19 11:23:09 4: 192.168.0.35 not found in cache
2021.01.19 11:23:09 2: Defined real device steinr for 192.168.0.35 as model shelly1pm
2021.01.19 11:23:09 5: URI: /cit/s, global_devid = SHSW-PM#68C63AFB701A#2, validity=3840, serial=3788
2021.01.19 11:23:09 5: Found device steinr, model shelly1pm
2021.01.19 11:23:09 5: cfgChanged = 1
2021.01.19 11:23:09 5: output_0 = 1
2021.01.19 11:23:09 5: input_0 = 0
2021.01.19 11:23:09 5: inputEvent_0 =
2021.01.19 11:23:09 5: inputEventCnt_0 = 0
2021.01.19 11:23:09 5: power_0 = 0
2021.01.19 11:23:09 5: energy_0 = 0
2021.01.19 11:23:09 5: overpower_0 = 0
2021.01.19 11:23:09 5: overpowerValue = 0
2021.01.19 11:23:09 5: deviceTemp = 29.86
2021.01.19 11:23:09 5: deviceTemp = 85.75
2021.01.19 11:23:09 5: overtemp = 0
2021.01.19 11:23:10 4: Received data from 192.168.0.27
2021.01.19 11:23:10 4: 192.168.0.27: in cache, devices=Badlicht (size=1)
2021.01.19 11:23:10 5: URI: /cit/s, global_devid = SHSW-1#4FFF80#2, validity=3840, serial=63
2021.01.19 11:23:10 5: Found device Badlicht, model shelly1
2021.01.19 11:23:10 5: cfgChanged = 1
2021.01.19 11:23:10 5: output_0 = 0
2021.01.19 11:23:10 5: input_0 = 0
2021.01.19 11:23:10 5: inputEvent_0 =
2021.01.19 11:23:10 5: inputEventCnt_0 = 0
2021.01.19 11:23:10 4: Received data from 192.168.0.50
2021.01.19 11:23:10 4: 192.168.0.50: in cache, devices=LichtTreppeE_1 (size=1)
2021.01.19 11:23:10 5: URI: /cit/s, global_devid = SHSW-1#1D97D9#2, validity=3840, serial=24
2021.01.19 11:23:10 5: Found device LichtTreppeE_1, model shelly1
2021.01.19 11:23:10 5: cfgChanged = 1
2021.01.19 11:23:10 5: output_0 = 0
2021.01.19 11:23:10 5: input_0 = 1
2021.01.19 11:23:10 5: inputEvent_0 =
2021.01.19 11:23:10 5: inputEventCnt_0 = 0
2021.01.19 11:23:10 4: Received data from 192.168.0.51
2021.01.19 11:23:10 4: 192.168.0.51: in cache, devices=LichtTreppe1_2 (size=1)
2021.01.19 11:23:10 5: URI: /cit/s, global_devid = SHSW-1#1D908C#2, validity=3840, serial=8
2021.01.19 11:23:10 5: Found device LichtTreppe1_2, model shelly1
2021.01.19 11:23:10 5: cfgChanged = 1
2021.01.19 11:23:10 5: output_0 = 0
2021.01.19 11:23:10 5: input_0 = 0
2021.01.19 11:23:10 5: inputEvent_0 =
2021.01.19 11:23:10 5: inputEventCnt_0 = 0
2021.01.19 11:23:13 4: Received data from 192.168.0.21
2021.01.19 11:23:13 4: 192.168.0.21: in cache, devices=GaesteWC (size=1)
2021.01.19 11:23:13 5: URI: /cit/s, global_devid = SHSW-1#500284#2, validity=3840, serial=59
2021.01.19 11:23:13 5: Found device GaesteWC, model shelly1
2021.01.19 11:23:13 5: cfgChanged = 1
2021.01.19 11:23:13 5: output_0 = 0
2021.01.19 11:23:13 5: input_0 = 1
2021.01.19 11:23:13 5: inputEvent_0 =
2021.01.19 11:23:13 5: inputEventCnt_0 = 0
2021.01.19 11:23:14 4: Received data from 192.168.0.115
2021.01.19 11:23:14 4: 192.168.0.115: in cache, devices=Trockner_16A (size=1)
2021.01.19 11:23:14 5: URI: /cit/s, global_devid = SHPLG2-1#2F562B#2, validity=3840, serial=3797
2021.01.19 11:23:14 5: Found device Trockner_16A, model shellyplug
2021.01.19 11:23:14 5: cfgChanged = 2
2021.01.19 11:23:14 5: output_0 = 1
2021.01.19 11:23:14 5: power_0 = 0
2021.01.19 11:23:14 5: energy_0 = 0
2021.01.19 11:23:14 5: overpower_0 = 0
2021.01.19 11:23:14 5: overpowerValue = 0
2021.01.19 11:23:14 4: Received data from 192.168.0.20
2021.01.19 11:23:14 4: 192.168.0.20: in cache, devices=Kuechenlicht (size=1)
2021.01.19 11:23:14 5: URI: /cit/s, global_devid = SHSW-1#1D9536#2, validity=3840, serial=8
2021.01.19 11:23:14 5: Found device Kuechenlicht, model shelly1
2021.01.19 11:23:14 5: cfgChanged = 1
2021.01.19 11:23:14 5: output_0 = 0
2021.01.19 11:23:14 5: input_0 = 0
2021.01.19 11:23:14 5: inputEvent_0 =
2021.01.19 11:23:14 5: inputEventCnt_0 = 0
2021.01.19 11:23:14 4: Received data from 192.168.0.11
2021.01.19 11:23:14 4: 192.168.0.11: in cache, devices=Waschmaschine (size=1)
2021.01.19 11:23:14 5: URI: /cit/s, global_devid = SHPLG2-1#2F52D8#2, validity=3840, serial=1389
2021.01.19 11:23:14 5: Found device Waschmaschine, model shellyplug
2021.01.19 11:23:14 5: cfgChanged = 2
2021.01.19 11:23:14 5: output_0 = 1
2021.01.19 11:23:14 5: power_0 = 0
2021.01.19 11:23:14 5: energy_0 = 2
2021.01.19 11:23:14 5: overpower_0 = 0
2021.01.19 11:23:14 5: overpowerValue = 0
2021.01.19 11:23:14 4: Received data from 192.168.0.12
2021.01.19 11:23:14 4: 192.168.0.12: in cache, devices=Vitrine (size=1)
2021.01.19 11:23:14 5: URI: /cit/s, global_devid = SHPLG-S#7AE825#2, validity=3840, serial=3797
2021.01.19 11:23:14 5: Found device Vitrine, model shellyplug
2021.01.19 11:23:14 5: cfgChanged = 1
2021.01.19 11:23:14 5: output_0 = 0
2021.01.19 11:23:14 5: power_0 = 0
2021.01.19 11:23:14 5: energy_0 = 0
2021.01.19 11:23:14 5: overpower_0 = 0
2021.01.19 11:23:14 5: overpowerValue = 0
2021.01.19 11:23:14 5: deviceTemp = 31.32
2021.01.19 11:23:14 5: deviceTemp = 88.38
2021.01.19 11:23:14 5: overtemp = 0
2021.01.19 11:23:15 4: Received data from 192.168.0.14
2021.01.19 11:23:15 4: 192.168.0.14 not found in cache
2021.01.19 11:23:15 2: Defined real device Spuelmaschine for 192.168.0.14 as model shellyplug
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHPLG-S#3CF173#2, validity=3840, serial=4160
2021.01.19 11:23:15 5: Found device Spuelmaschine, model shellyplug
2021.01.19 11:23:15 5: cfgChanged = 1
2021.01.19 11:23:15 5: output_0 = 1
2021.01.19 11:23:15 5: power_0 = 0.55
2021.01.19 11:23:15 5: energy_0 = 178937
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: overpowerValue = 0
2021.01.19 11:23:15 5: deviceTemp = 28.02
2021.01.19 11:23:15 5: deviceTemp = 82.44
2021.01.19 11:23:15 5: overtemp = 0
2021.01.19 11:23:15 4: Received data from 192.168.0.13
2021.01.19 11:23:15 4: 192.168.0.13 not found in cache
2021.01.19 11:23:15 2: Defined real device Salzlampe for 192.168.0.13 as model shellyplug
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHPLG-S#7AE079#2, validity=3840, serial=3808
2021.01.19 11:23:15 5: Found device Salzlampe, model shellyplug
2021.01.19 11:23:15 5: cfgChanged = 1
2021.01.19 11:23:15 5: output_0 = 0
2021.01.19 11:23:15 5: power_0 = 0
2021.01.19 11:23:15 5: energy_0 = 318
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: overpowerValue = 0
2021.01.19 11:23:15 5: deviceTemp = 32.59
2021.01.19 11:23:15 5: deviceTemp = 90.66
2021.01.19 11:23:15 5: overtemp = 0
2021.01.19 11:23:15 4: Received data from 192.168.0.66
2021.01.19 11:23:15 4: 192.168.0.66: in cache, devices=LED_Schlafzimmer (size=1)
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHRGBW2#66130A#2, validity=3840, serial=185
2021.01.19 11:23:15 5: Found device LED_Schlafzimmer, model shellyrgbw
2021.01.19 11:23:15 5: cfgChanged = 0
2021.01.19 11:23:15 5: output_0 = 0
2021.01.19 11:23:15 5: L-red = 18
2021.01.19 11:23:15 5: L-green = 133
2021.01.19 11:23:15 5: L-blue = 106
2021.01.19 11:23:15 5: L-white = 0
2021.01.19 11:23:15 5: gain = 14
2021.01.19 11:23:15 5: power_0 = 0
2021.01.19 11:23:15 5: energy_0 = 0
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: input_0 = 0
2021.01.19 11:23:15 5: inputEvent_0 =
2021.01.19 11:23:15 5: inputEventCnt_0 = 0
2021.01.19 11:23:15 5: mode = color
2021.01.19 11:23:15 4: Received data from 192.168.0.26
2021.01.19 11:23:15 4: 192.168.0.26 not found in cache
2021.01.19 11:23:15 2: Defined real device MarcelsBrunnen for 192.168.0.26 as model shellyplug
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHPLG-S#7AF180#2, validity=3840, serial=3799
2021.01.19 11:23:15 5: Found device MarcelsBrunnen, model shellyplug
2021.01.19 11:23:15 5: cfgChanged = 2
2021.01.19 11:23:15 5: output_0 = 0
2021.01.19 11:23:15 5: power_0 = 0
2021.01.19 11:23:15 5: energy_0 = 0
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: overpowerValue = 0
2021.01.19 11:23:15 5: deviceTemp = 31.99
2021.01.19 11:23:15 5: deviceTemp = 89.58
2021.01.19 11:23:15 5: overtemp = 0
2021.01.19 11:23:15 1: Panic, it happened: Cache for 192.168.0.13 did contain a none-hash
2021.01.19 11:23:15 1: Panic, it happened: Cache for 192.168.0.14 did contain a none-hash
2021.01.19 11:23:15 1: Panic, it happened: Cache for 192.168.0.26 did contain a none-hash
2021.01.19 11:23:15 1: Panic, it happened: Cache for 192.168.0.35 did contain a none-hash
2021.01.19 11:23:15 4: Received data from 192.168.0.70
2021.01.19 11:23:15 4: 192.168.0.70 not found in cache
2021.01.19 11:23:15 2: Defined real device Buerolicht for 192.168.0.70 as model shellydimmer
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHDM-1#420085#2, validity=3840, serial=2689
2021.01.19 11:23:15 5: Found device Buerolicht, model shellydimmer
2021.01.19 11:23:15 5: cfgChanged = 4
2021.01.19 11:23:15 5: output_0 = 0
2021.01.19 11:23:15 5: brightness_0 = 100
2021.01.19 11:23:15 5: input_0 = 0
2021.01.19 11:23:15 5: inputEvent_0 = S
2021.01.19 11:23:15 5: inputEventCnt_0 = 21
2021.01.19 11:23:15 5: input_1 = 0
2021.01.19 11:23:15 5: inputEvent_1 =
2021.01.19 11:23:15 5: inputEventCnt_1 = 0
2021.01.19 11:23:15 5: power_0 = 0
2021.01.19 11:23:15 5: energy_0 = 3218
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: overpowerValue = 0
2021.01.19 11:23:15 5: loadError = 0
2021.01.19 11:23:15 5: deviceTemp = 49.57
2021.01.19 11:23:15 5: deviceTemp = 121.22
2021.01.19 11:23:15 5: overtemp = 0
2021.01.19 11:23:15 5: mode = white
2021.01.19 11:23:15 4: Received data from 192.168.0.34
2021.01.19 11:23:15 4: 192.168.0.34 not found in cache
2021.01.19 11:23:15 2: Defined real device steinl for 192.168.0.34 as model shelly2.5
2021.01.19 11:23:15 2: Defined real device steinr2_unused for 192.168.0.34 as model shelly2.5
2021.01.19 11:23:15 5: URI: /cit/s, global_devid = SHSW-25#5DB792#2, validity=3840, serial=3786
2021.01.19 11:23:15 5: Found device steinl, model shelly2.5
2021.01.19 11:23:15 5: Found device steinr2_unused, model shelly2.5
2021.01.19 11:23:15 5: cfgChanged = 1
2021.01.19 11:23:15 5: output_0 = 0
2021.01.19 11:23:15 5: output_1 = 0
2021.01.19 11:23:15 5: input_0 = 0
2021.01.19 11:23:15 5: inputEvent_0 =
2021.01.19 11:23:15 5: inputEventCnt_0 = 0
2021.01.19 11:23:15 5: input_1 = 0
2021.01.19 11:23:15 5: inputEvent_1 =
2021.01.19 11:23:15 5: inputEventCnt_1 = 0
2021.01.19 11:23:15 5: power_0 = 0
2021.01.19 11:23:15 5: energy_0 = 0
2021.01.19 11:23:15 5: overpower_0 = 0
2021.01.19 11:23:15 5: power_1 = 0
2021.01.19 11:23:15 5: energy_1 = 0
2021.01.19 11:23:15 5: overpower_1 = 0
2021.01.19 11:23:15 5: deviceTemp = 37.1
2021.01.19 11:23:15 5: overtemp = 0
2021.01.19 11:23:15 5: mode = relay
2021.01.19 11:23:16 4: Received data from 192.168.0.31
2021.01.19 11:23:16 4: 192.168.0.31 not found in cache
2021.01.19 11:23:16 2: Defined real device steinlo for 192.168.0.31 as model shelly2.5
2021.01.19 11:23:16 2: Defined real device steinlu for 192.168.0.31 as model shelly2.5
2021.01.19 11:23:16 5: URI: /cit/s, global_devid = SHSW-25#74495A#2, validity=3840, serial=3786
2021.01.19 11:23:16 5: Found device steinlo, model shelly2.5
2021.01.19 11:23:16 5: Found device steinlu, model shelly2.5
2021.01.19 11:23:16 5: cfgChanged = 1
2021.01.19 11:23:16 5: output_0 = 0
2021.01.19 11:23:16 5: output_1 = 0
2021.01.19 11:23:16 5: input_0 = 0
2021.01.19 11:23:16 5: inputEvent_0 =
2021.01.19 11:23:16 5: inputEventCnt_0 = 0
2021.01.19 11:23:16 5: input_1 = 0
2021.01.19 11:23:16 5: inputEvent_1 =
2021.01.19 11:23:16 5: inputEventCnt_1 = 0
2021.01.19 11:23:16 5: power_0 = 0
2021.01.19 11:23:16 5: energy_0 = 0
2021.01.19 11:23:16 5: overpower_0 = 0
2021.01.19 11:23:16 5: power_1 = 0
2021.01.19 11:23:16 5: energy_1 = 0
2021.01.19 11:23:16 5: overpower_1 = 0
2021.01.19 11:23:16 5: deviceTemp = 31.6
2021.01.19 11:23:16 5: overtemp = 0
2021.01.19 11:23:16 5: mode = relay
2021.01.19 11:23:16 4: Received data from 192.168.0.30
2021.01.19 11:23:16 4: 192.168.0.30: in cache, devices=brunnen (size=1)
2021.01.19 11:23:16 5: URI: /cit/s, global_devid = SHSW-1#50053B#2, validity=3840, serial=2
2021.01.19 11:23:16 5: Found device brunnen, model shelly1
2021.01.19 11:23:16 5: cfgChanged = 1
2021.01.19 11:23:16 5: output_0 = 0
2021.01.19 11:23:16 5: input_0 = 1
2021.01.19 11:23:16 5: inputEvent_0 = L
2021.01.19 11:23:16 5: inputEventCnt_0 = 1
2021.01.19 11:23:17 4: Received data from 192.168.0.24
2021.01.19 11:23:17 4: 192.168.0.24: in cache, devices=Kugellampe (size=1)
2021.01.19 11:23:17 5: URI: /cit/s, global_devid = SHSW-1#59E51D#2, validity=3840, serial=17
2021.01.19 11:23:17 5: Found device Kugellampe, model shelly1
2021.01.19 11:23:17 5: cfgChanged = 1
2021.01.19 11:23:17 5: output_0 = 0
2021.01.19 11:23:17 5: input_0 = 0
2021.01.19 11:23:17 5: inputEvent_0 = S
2021.01.19 11:23:17 5: inputEventCnt_0 = 9
2021.01.19 11:23:19 4: Received data from 192.168.0.32
2021.01.19 11:23:19 4: 192.168.0.32 not found in cache
2021.01.19 11:23:19 2: Defined real device steinro for 192.168.0.32 as model shelly2.5
2021.01.19 11:23:19 2: Defined real device steinru for 192.168.0.32 as model shelly2.5
2021.01.19 11:23:19 5: URI: /cit/s, global_devid = SHSW-25#5DBE9F#2, validity=3840, serial=3785
2021.01.19 11:23:19 5: Found device steinro, model shelly2.5
2021.01.19 11:23:19 5: Found device steinru, model shelly2.5
2021.01.19 11:23:19 5: cfgChanged = 1
2021.01.19 11:23:19 5: output_0 = 0
2021.01.19 11:23:19 5: output_1 = 0
2021.01.19 11:23:19 5: input_0 = 0
2021.01.19 11:23:19 5: inputEvent_0 =
2021.01.19 11:23:19 5: inputEventCnt_0 = 0
2021.01.19 11:23:19 5: input_1 = 0
2021.01.19 11:23:19 5: inputEvent_1 =
2021.01.19 11:23:19 5: inputEventCnt_1 = 0
2021.01.19 11:23:19 5: power_0 = 0
2021.01.19 11:23:19 5: energy_0 = 0
2021.01.19 11:23:19 5: overpower_0 = 0
2021.01.19 11:23:19 5: power_1 = 0
2021.01.19 11:23:19 5: energy_1 = 0
2021.01.19 11:23:19 5: overpower_1 = 0
2021.01.19 11:23:19 5: deviceTemp = 32.65
2021.01.19 11:23:19 5: overtemp = 0
2021.01.19 11:23:19 5: mode = relay
2021.01.19 11:23:19 4: Received data from 192.168.0.40
2021.01.19 11:23:19 4: 192.168.0.40: in cache, devices=Porzellanlampe (size=1)
2021.01.19 11:23:19 5: URI: /cit/s, global_devid = SHSW-1#93B01E#2, validity=3840, serial=7
2021.01.19 11:23:19 5: Found device Porzellanlampe, model shelly1
2021.01.19 11:23:19 5: cfgChanged = 1
2021.01.19 11:23:19 5: output_0 = 0
2021.01.19 11:23:19 5: input_0 = 0
2021.01.19 11:23:19 5: inputEvent_0 =
2021.01.19 11:23:19 5: inputEventCnt_0 = 0
2021.01.19 11:23:20 1: Panic, it happened: Cache for 192.168.0.31 did contain a none-hash
2021.01.19 11:23:20 1: Panic, it happened: Cache for 192.168.0.32 did contain a none-hash
2021.01.19 11:23:20 1: Panic, it happened: Cache for 192.168.0.34 did contain a none-hash
2021.01.19 11:23:20 1: Panic, it happened: Cache for 192.168.0.70 did contain a none-hash
2021.01.19 11:23:21 4: Received data from 192.168.0.23
2021.01.19 11:23:21 4: 192.168.0.23: in cache, devices=Flur (size=1)
2021.01.19 11:23:21 5: URI: /cit/s, global_devid = SHSW-1#5006E7#2, validity=3840, serial=23
2021.01.19 11:23:21 5: Found device Flur, model shelly1
2021.01.19 11:23:21 5: cfgChanged = 4
2021.01.19 11:23:21 5: output_0 = 0
2021.01.19 11:23:21 5: input_0 = 1
2021.01.19 11:23:21 5: inputEvent_0 =
2021.01.19 11:23:21 5: inputEventCnt_0 = 0
2021.01.19 11:23:21 4: Received data from 192.168.0.22
2021.01.19 11:23:21 4: 192.168.0.22 not found in cache
2021.01.19 11:23:21 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 11:23:21 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 11:23:21 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8607
2021.01.19 11:23:21 5: Found device Couch, model shelly2
2021.01.19 11:23:21 5: Found device Esstisch, model shelly2
2021.01.19 11:23:21 5: cfgChanged = 0
2021.01.19 11:23:21 5: output_0 = 0
2021.01.19 11:23:21 5: output_1 = 0
2021.01.19 11:23:21 5: input_0 = 0
2021.01.19 11:23:21 5: inputEvent_0 =
2021.01.19 11:23:21 5: inputEventCnt_0 = 0
2021.01.19 11:23:21 5: input_1 = 0
2021.01.19 11:23:21 5: inputEvent_1 =
2021.01.19 11:23:21 5: inputEventCnt_1 = 0
2021.01.19 11:23:21 5: power_0 = 0
2021.01.19 11:23:21 5: energy_0 = 10297
2021.01.19 11:23:21 5: overpowerValue = 0
2021.01.19 11:23:21 5: overpower_0 = 0
2021.01.19 11:23:21 5: overpower_1 = 0
2021.01.19 11:23:21 5: mode = relay
2021.01.19 11:23:22 4: Received data from 192.168.0.22
2021.01.19 11:23:22 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 11:23:22 4: 192.168.0.22 not found in cache
2021.01.19 11:23:22 2: Defined real device Couch for 192.168.0.22 as model shelly2
2021.01.19 11:23:22 2: Defined real device Esstisch for 192.168.0.22 as model shelly2
2021.01.19 11:23:22 5: URI: /cit/s, global_devid = SHSW-21#559CCF#2, validity=3840, serial=8608
2021.01.19 11:23:22 5: Found device Couch, model shelly2
2021.01.19 11:23:22 5: Found device Esstisch, model shelly2
2021.01.19 11:23:22 5: cfgChanged = 0
2021.01.19 11:23:22 5: output_0 = 0
2021.01.19 11:23:22 5: output_1 = 0
2021.01.19 11:23:22 5: input_0 = 0
2021.01.19 11:23:22 5: inputEvent_0 =
2021.01.19 11:23:22 5: inputEventCnt_0 = 0
2021.01.19 11:23:22 5: input_1 = 0
2021.01.19 11:23:22 5: inputEvent_1 =
2021.01.19 11:23:22 5: inputEventCnt_1 = 0
2021.01.19 11:23:22 5: power_0 = 0
2021.01.19 11:23:22 5: energy_0 = 10297
2021.01.19 11:23:22 5: overpowerValue = 0
2021.01.19 11:23:22 5: overpower_0 = 0
2021.01.19 11:23:22 5: overpower_1 = 0
2021.01.19 11:23:22 5: mode = relay
2021.01.19 11:23:23 4: Received data from 192.168.0.29
2021.01.19 11:23:23 4: 192.168.0.29: in cache, devices=dachlicht (size=1)
2021.01.19 11:23:23 5: URI: /cit/s, global_devid = SHSW-1#1D99DC#2, validity=3840, serial=4
2021.01.19 11:23:23 5: Found device dachlicht, model shelly1
2021.01.19 11:23:23 5: cfgChanged = 1
2021.01.19 11:23:23 5: output_0 = 0
2021.01.19 11:23:23 5: input_0 = 0
2021.01.19 11:23:23 5: inputEvent_0 =
2021.01.19 11:23:23 5: inputEventCnt_0 = 0
2021.01.19 11:23:24 1: Panic, it happened: Cache for 192.168.0.22 did contain a none-hash
2021.01.19 11:23:24 4: Received data from 192.168.0.28
2021.01.19 11:23:24 4: 192.168.0.28: in cache, devices=Schlafzimmer (size=1)
2021.01.19 11:23:24 5: URI: /cit/s, global_devid = SHSW-1#500DC0#2, validity=3840, serial=14
2021.01.19 11:23:24 5: Found device Schlafzimmer, model shelly1
2021.01.19 11:23:24 5: cfgChanged = 1
2021.01.19 11:23:24 5: output_0 = 0
2021.01.19 11:23:24 5: input_0 = 0
2021.01.19 11:23:24 5: inputEvent_0 =
2021.01.19 11:23:24 5: inputEventCnt_0 = 0
2021.01.19 11:23:24 4: Received data from 192.168.0.35
2021.01.19 11:23:24 4: 192.168.0.35 not found in cache
2021.01.19 11:23:24 2: Defined real device steinr for 192.168.0.35 as model shelly1pm
2021.01.19 11:23:24 5: URI: /cit/s, global_devid = SHSW-PM#68C63AFB701A#2, validity=3840, serial=3788
2021.01.19 11:23:24 5: Found device steinr, model shelly1pm
2021.01.19 11:23:24 5: cfgChanged = 1
2021.01.19 11:23:24 5: output_0 = 1
2021.01.19 11:23:24 5: input_0 = 0
2021.01.19 11:23:24 5: inputEvent_0 =
2021.01.19 11:23:24 5: inputEventCnt_0 = 0
2021.01.19 11:23:24 5: power_0 = 0
2021.01.19 11:23:24 5: energy_0 = 0
2021.01.19 11:23:24 5: overpower_0 = 0
2021.01.19 11:23:24 5: overpowerValue = 0
2021.01.19 11:23:24 5: deviceTemp = 29.98
2021.01.19 11:23:24 5: deviceTemp = 85.96
2021.01.19 11:23:24 5: overtemp = 0
2021.01.19 11:23:25 4: Received data from 192.168.0.27
2021.01.19 11:23:25 4: 192.168.0.27: in cache, devices=Badlicht (size=1)
2021.01.19 11:23:25 5: URI: /cit/s, global_devid = SHSW-1#4FFF80#2, validity=3840, serial=63
2021.01.19 11:23:25 5: Found device Badlicht, model shelly1
2021.01.19 11:23:25 5: cfgChanged = 1
2021.01.19 11:23:25 5: output_0 = 0
2021.01.19 11:23:25 5: input_0 = 0
2021.01.19 11:23:25 5: inputEvent_0 =
2021.01.19 11:23:25 5: inputEventCnt_0 = 0
2021.01.19 11:23:25 4: Received data from 192.168.0.50
2021.01.19 11:23:25 4: 192.168.0.50: in cache, devices=LichtTreppeE_1 (size=1)
2021.01.19 11:23:25 5: URI: /cit/s, global_devid = SHSW-1#1D97D9#2, validity=3840, serial=24
2021.01.19 11:23:25 5: Found device LichtTreppeE_1, model shelly1
2021.01.19 11:23:25 5: cfgChanged = 1
2021.01.19 11:23:25 5: output_0 = 0
2021.01.19 11:23:25 5: input_0 = 1
2021.01.19 11:23:25 5: inputEvent_0 =
2021.01.19 11:23:25 5: inputEventCnt_0 = 0
2021.01.19 11:23:26 4: Received data from 192.168.0.51
2021.01.19 11:23:26 4: 192.168.0.51: in cache, devices=LichtTreppe1_2 (size=1)
2021.01.19 11:23:26 5: URI: /cit/s, global_devid = SHSW-1#1D908C#2, validity=3840, serial=8
2021.01.19 11:23:26 5: Found device LichtTreppe1_2, model shelly1
2021.01.19 11:23:26 5: cfgChanged = 1
2021.01.19 11:23:26 5: output_0 = 0
2021.01.19 11:23:26 5: input_0 = 0
2021.01.19 11:23:26 5: inputEvent_0 =
2021.01.19 11:23:26 5: inputEventCnt_0 = 0
2021.01.19 11:23:28 4: Received data from 192.168.0.21
2021.01.19 11:23:28 4: 192.168.0.21: in cache, devices=GaesteWC (size=1)
2021.01.19 11:23:28 5: URI: /cit/s, global_devid = SHSW-1#500284#2, validity=3840, serial=59
2021.01.19 11:23:28 5: Found device GaesteWC, model shelly1
2021.01.19 11:23:28 5: cfgChanged = 1
2021.01.19 11:23:28 5: output_0 = 0
2021.01.19 11:23:28 5: input_0 = 1
2021.01.19 11:23:28 5: inputEvent_0 =
2021.01.19 11:23:28 5: inputEventCnt_0 = 0
2021.01.19 11:23:29 4: Received data from 192.168.0.115
2021.01.19 11:23:29 4: 192.168.0.115: in cache, devices=Trockner_16A (size=1)
2021.01.19 11:23:29 5: URI: /cit/s, global_devid = SHPLG2-1#2F562B#2, validity=3840, serial=3797
2021.01.19 11:23:29 5: Found device Trockner_16A, model shellyplug
2021.01.19 11:23:29 5: cfgChanged = 2
2021.01.19 11:23:29 5: output_0 = 1
2021.01.19 11:23:29 5: power_0 = 0
2021.01.19 11:23:29 5: energy_0 = 0
2021.01.19 11:23:29 5: overpower_0 = 0
2021.01.19 11:23:29 5: overpowerValue = 0
2021.01.19 11:23:29 4: Received data from 192.168.0.20
2021.01.19 11:23:29 4: 192.168.0.20: in cache, devices=Kuechenlicht (size=1)
2021.01.19 11:23:29 5: URI: /cit/s, global_devid = SHSW-1#1D9536#2, validity=3840, serial=8
2021.01.19 11:23:29 5: Found device Kuechenlicht, model shelly1
2021.01.19 11:23:29 5: cfgChanged = 1
2021.01.19 11:23:29 5: output_0 = 0
2021.01.19 11:23:29 5: input_0 = 0
2021.01.19 11:23:29 5: inputEvent_0 =
2021.01.19 11:23:29 5: inputEventCnt_0 = 0
2021.01.19 11:23:29 4: Received data from 192.168.0.11
2021.01.19 11:23:29 4: 192.168.0.11: in cache, devices=Waschmaschine (size=1)
2021.01.19 11:23:29 5: URI: /cit/s, global_devid = SHPLG2-1#2F52D8#2, validity=3840, serial=1389
2021.01.19 11:23:29 5: Found device Waschmaschine, model shellyplug
2021.01.19 11:23:29 5: cfgChanged = 2
2021.01.19 11:23:29 5: output_0 = 1
2021.01.19 11:23:29 5: power_0 = 0
2021.01.19 11:23:29 5: energy_0 = 2
2021.01.19 11:23:29 5: overpower_0 = 0
2021.01.19 11:23:29 5: overpowerValue = 0
2021.01.19 11:23:29 4: Received data from 192.168.0.12
2021.01.19 11:23:29 4: 192.168.0.12: in cache, devices=Vitrine (size=1)
2021.01.19 11:23:29 5: URI: /cit/s, global_devid = SHPLG-S#7AE825#2, validity=3840, serial=3797
2021.01.19 11:23:29 5: Found device Vitrine, model shellyplug
2021.01.19 11:23:29 5: cfgChanged = 1
2021.01.19 11:23:29 5: output_0 = 0
2021.01.19 11:23:29 5: power_0 = 0
2021.01.19 11:23:29 5: energy_0 = 0
2021.01.19 11:23:29 5: overpower_0 = 0
2021.01.19 11:23:29 5: overpowerValue = 0
2021.01.19 11:23:29 5: deviceTemp = 31.38
2021.01.19 11:23:29 5: deviceTemp = 88.48
2021.01.19 11:23:29 5: overtemp = 0


Scheint nicht zu helfen

Zitat von: gvzdus am 19 Januar 2021, 10:12:07

Code Auswählen Erweitern

Das ist problematisch, z.B. für Floods und DW's, die sich eventuell nur alle 6 Stunden melden (bei mir im Normalfall erst nach 24 Stunden).

Ich gehe davon aus, dass Floods & Co. hier eine höhere Validity-Periode senden, denn dafür ist der Wert ja angegeben und variabel. Ich habe allerdings keine entsprechenden Geräte, und bisher immer nur den "gut 1 Stunde"-Wert gesehen.

Meine Floods melden sich alle 24 Stunden und die Thermometer ca 6-9 Stunden. Dadurch werden Sie zur Zeit immer angelegt und gelöscht. Würde ich gerne auch vermeiden. Alles andere funktioniert bei mir gut! Danke dafür!

Gruss
  Enno

Ad 1) Ich konnte den Fehler reproduzieren - ich mutmaße, dass ich mit den Array-Referenzen schlampert umgegangen bin.
Anbei die Version, die bei mir keine "Panics" mehr produziert. Würde mich über Rückmeldung freuen.

Ad Enno:
Meine Floods melden sich alle 24 Stunden und die Thermometer ca 6-9 Stunden.
Heisst: Du hast sie real mit dem Modul getestet? Und Shelly hat einen Bug in ihrer CoIoT-Implementierung, dass die Validity eben bei 1 h bleibt, obwohl sie ja wissen, dass sie sich in diesem Interval nicht wiedermelden werden?

Dann frage ich mich 2 Dinge:

• Du hast die Flood & Thermometer dann ja wohl als Device angelegt. Wie sehen die Readings aus, die ankommen? Kann man behaupten: "Läuft mit dem Modul!"?
• ShellyMonitor sollte nur in der Tabelle Geräte "vergessen", deren Validity abgelaufen ist. Gelöscht werden aber real angelegte Geräte nie.

 Flood & Thermometer dann ja wohl als Device angelegt? Beides. Ich habe zwei  Flood. Eines habe ich angelegt, das zweite nicht. Readings kommen bei dem angelegten Device keine an. Das Device das ich angelegt habe wird auch nicht gelöscht, Also halb ok soweit.

ZitatInternals:
   DEF        192.168.179.172
   DURATION   0
   FUUID      60068cfb-f33f-9270-3716-04a1eb0a12165b69
   INTERVAL   0
   NAME       EG_K_Wassermelder_Shelly
   NR         1065
   SHELLYID   76527C
   STATE      Error
   TCPIP      192.168.179.172
   TYPE       Shelly
   READINGS:
     2021-01-19 10:18:03   network         not connected
     2021-01-19 10:18:03   state           Error
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   interval   0
   model      generic
   room       Shelly

• ShellyMonitor sollte nur in der Tabelle Geräte "vergessen", deren Validity abgelaufen ist. Gelöscht werden aber real angelegte Geräte nie.

Das passt, ich bekomme für Geräte die nicht angelegt werden ein shadow_device. Das wird dann nach Ablauf der Validity wieder gelöscht. Am nächsten Tag die gleichen Einträge im Log wieder.

Das Thermometer habe ich auch angelegt. Hier kommen nur Fahrenheit, keine C°...

ZitatInternals:
   DEF        192.168.179.175
   DURATION   0
   FUUID      60049237-f33f-9270-70b0-2f58ec6591c8cac0
   INTERVAL   0
   NAME       Thermo_OG_JM_Shelly
   NR         1063
   SHELLYID   E00DA8
   STATE      Error
   TCPIP      192.168.179.175
   TYPE       Shelly
   READINGS:
     2021-01-17 20:38:33   battery         100
     2021-01-17 20:43:24   cfgChanged      0
     2021-01-17 20:38:32   cloud           disabled
     2021-01-19 09:59:38   extTemp_0       70.7
     2021-01-17 20:38:32   firmware        v1.9.0
     2021-01-19 09:59:08   humidity        46
     2021-01-19 10:18:03   network         not connected
     2021-01-17 20:38:33   sensorError     0
     2021-01-19 10:18:03   state           Error
     2021-01-19 09:59:38   wakeupEvent     ARRAY(0x5572eca93ea0)
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   interval   0
   model      generic
   room       Shelly

Noch irgendetwas womit ich helfen kann?

Gruss
  Enno

Zitat von: gvzdus am 19 Januar 2021, 13:01:09
Ad 1) Ich konnte den Fehler reproduzieren - ich mutmaße, dass ich mit den Array-Referenzen schlampert umgegangen bin.
Anbei die Version, die bei mir keine "Panics" mehr produziert. Würde mich über Rückmeldung freuen.

Ad Enno:

Code Auswählen Erweitern

Meine Floods melden sich alle 24 Stunden und die Thermometer ca 6-9 Stunden.
Heisst: Du hast sie real mit dem Modul getestet? Und Shelly hat einen Bug in ihrer CoIoT-Implementierung, dass die Validity eben bei 1 h bleibt, obwohl sie ja wissen, dass sie sich in diesem Interval nicht wiedermelden werden?

Dann frage ich mich 2 Dinge:

• Du hast die Flood & Thermometer dann ja wohl als Device angelegt. Wie sehen die Readings aus, die ankommen? Kann man behaupten: "Läuft mit dem Modul!"?
• ShellyMonitor sollte nur in der Tabelle Geräte "vergessen", deren Validity abgelaufen ist. Gelöscht werden aber real angelegte Geräte nie.

Mit dieser Version ist das Problem scheinbar beseitigt,
keine Refresh mehr und keine dauernden Einträge im Log

@bombardi: Danke, puh!

@Enno:
Beim Flood vermute ich, dass noch kein Event reingekommen ist. Oder kannst Du mir das Gegenteil "beweisen" - nach dem Motto: Ich sehe im Log, das ein Paket reinkam, aber offensichtlich kein Reading geschrieben wurde?

Zum Thermometer:
Anbei - Überraschung - eine neue Version:

• Die Shellys rotzen C und Fahrenheit raus, ich habe jetzt dem Fahrenheit-Reading einen anderen Namen gegeben, sodass es nicht C überschreibt.
• Was als "wakeupEvent" kommt, ist mal spannend. In der angehängten Version wird das Array geplättet, dann wird der Inhalt des Arrays sichtbar. Ich vermute mal, das wird auch für die Bewegungsmelder relevant werden. Oder wenn der Keller mal wirklich nass ist.

Ergänzung:
Bevor Du den Keller für die Shelly-Forschung flutest: Hier die Doku von Allterco:

ZitatFor battery operated (i.e. sleeping) devices (e.g. Shelly H&T) indicates why the device woke up. Please note that the payload for this property's value in status ("G") will be an array of strings with one or more elements, for example ["sensor","alarm"].

["battery/button/periodic/poweron/sensor/alarm","unknown"]

ok, hier zum Flood. Ich habe die Version hier zwei weiter oben eingespielt, und dann einen Eimer Wasser in den Keller gekippt:

Hier das Log und der Monitor. Ich habe zum vergleich die Meldung vom gleichen Device über MQTT2 mal mit aufgeführt.

2021.01.19 14:34:19 2: Defined real device KG_WK_Wassermelder_Shelly for 192.168.179.171 as model generic
2021.01.19 14:34:19 1: Assigning device KG_WK_Wassermelder_Shelly SHELLYID 694936

2021-01-19 14:34:20 MQTT2_DEVICE KG_WK_Wassermelder online: true
2021-01-19 14:34:20 MQTT2_DEVICE KG_WK_Wassermelder temperature: 15.38
2021-01-19 14:34:21 SiSi SIGNAL send 123== Wassermelder Waschküche Alarm! Status: true
2021-01-19 14:34:21 MQTT2_DEVICE KG_WK_Wassermelder flood: true

2021-01-19 14:40:37 MQTT2_DEVICE KG_WK_Wassermelder online: true
2021-01-19 14:40:37 MQTT2_DEVICE KG_WK_Wassermelder temperature: 16.50
2021-01-19 14:40:37 MQTT2_DEVICE KG_WK_Wassermelder flood: false
2021-01-19 14:40:55 MQTT2_DEVICE KG_WK_Wassermelder online: false

2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly cfgChanged: 0
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly extTemp_0: 999
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly extTemp_0f: 999
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly flood: -1
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly sensorError: 0
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly battery: -1
2021-01-19 14:45:15 Shelly KG_WK_Wassermelder_Shelly wakeupEvent: unknown
2021-01-19 14:45:16 MQTT2_DEVICE KG_WK_Wassermelder temperature: 0.00
2021-01-19 14:45:16 MQTT2_DEVICE KG_WK_Wassermelder batterylevel: 0
2021-01-19 14:45:17 Shelly KG_WK_Wassermelder_Shelly cfgChanged: 1
2021-01-19 14:45:20 MQTT2_DEVICE KG_WK_Wassermelder temperature: 22.62
2021-01-19 14:45:20 MQTT2_DEVICE KG_WK_Wassermelder batterylevel: 96
2021-01-19 14:45:20 Shelly KG_WK_Wassermelder_Shelly extTemp_0: 22.62
2021-01-19 14:45:20 Shelly KG_WK_Wassermelder_Shelly extTemp_0f: 72.72
2021-01-19 14:45:20 Shelly KG_WK_Wassermelder_Shelly flood: 0
2021-01-19 14:45:20 Shelly KG_WK_Wassermelder_Shelly battery: 96
2021-01-19 14:45:20 Shelly KG_WK_Wassermelder_Shelly wakeupEvent: poweron
2021-01-19 14:45:49 Shelly KG_WK_Wassermelder_Shelly network: <html>connected to <a href="http://192.168.179.171">192.168.179.171</a></html>
2021-01-19 14:45:49 Shelly KG_WK_Wassermelder_Shelly firmware: v1.9.2
2021-01-19 14:45:49 Shelly KG_WK_Wassermelder_Shelly cloud: disabled

2021-01-19 14:52:15 Shelly KG_WK_Wassermelder_Shelly cfgChanged: 0
2021-01-19 14:52:15 Shelly KG_WK_Wassermelder_Shelly flood: 1
2021-01-19 14:52:15 Shelly KG_WK_Wassermelder_Shelly wakeupEvent: alarm
2021-01-19 14:52:16 MQTT2_DEVICE KG_WK_Wassermelder online: true
2021-01-19 14:52:16 MQTT2_DEVICE KG_WK_Wassermelder flood: true
2021-01-19 14:54:46 Shelly KG_WK_Wassermelder_Shelly extTemp_0: 23.25
2021-01-19 14:54:46 Shelly KG_WK_Wassermelder_Shelly extTemp_0f: 73.85
2021-01-19 14:54:46 Shelly KG_WK_Wassermelder_Shelly flood: 0
2021-01-19 14:54:46 MQTT2_SERVER myBroker nrclients: 2
2021-01-19 14:54:47 MQTT2_DEVICE KG_WK_Wassermelder online: true
2021-01-19 14:54:47 MQTT2_DEVICE KG_WK_Wassermelder temperature: 23.25
2021-01-19 14:54:47 MQTT2_DEVICE KG_WK_Wassermelder flood: false

Die Readings kommen an und ich würde sagen, das geht! Nun gehe ich den Boden wischen...

Gruss
  Enno

Super, danke! Dann kann ich gedanklich an den Flood einen Haken machen. Sogar 1 Sekunde schneller als per MQTT :-)

Die Version ist jetzt eingecheckt und dann morgen im Update.

Hallo gvzdus,
ich habe gerade ein update gemacht und finde folgendes im Log:2021.01.19 15:41:26 1: Panic, it happened: Cache for 168.192.0.53 did contain a none-hash
2021.01.19 15:41:26 2: Defined real device Schalter_Kueche for 168.192.0.53 as model shelly1pm
2021.01.19 15:41:41 1: Panic, it happened: Cache for 168.192.0.53 did contain a none-hash
2021.01.19 15:41:41 2: Defined real device Schalter_Kueche for 168.192.0.53 as model shelly1pm

Warte bis Morgen 8 Uhr oder nimm die Version ein paar Beiträge oben und spiele sie per Hand ein!

ok, das Wasser ist aufgewischt und es wurde wärmer ;D das Thermometer hat sich gemeldet:

Internals:
   CFGFN     
   DEF        192.168.179.174
   DURATION   0
   FUUID      6006de9b-f33f-9270-99d9-c8c7cec47880e1e4
   INTERVAL   60
   NAME       Thermo_DG_DB_Shelly
   NR         17992
   SHELLYID   E0143E
   STATE      T: 19.88 °C H: 47.5 % B: 100
   TCPIP      192.168.179.174
   TYPE       Shelly
   Helper:
     DBLOG:
       dewpoint:
         MYSQL:
           TIME       1611069439.42282
           VALUE      10.23
       humidity:
         MYSQL:
           TIME       1611069439.42282
           VALUE      47.5
       network:
         MYSQL:
           TIME       1611062939.47264
           VALUE      <html>connected to <a href="http://192.168.179.175">192.168.179.175</a></html>
       state:
         MYSQL:
           TIME       1611062939.47264
           VALUE      initialized
       temperature:
         MYSQL:
           TIME       1611069439.42282
           VALUE      19.88
   READINGS:
     2021-01-19 15:43:04   battery         100
     2021-01-19 16:06:07   cfgChanged      0
     2021-01-19 15:34:21   cloud           disabled
     2021-01-19 16:17:19   dewpoint        10.23
     2021-01-19 16:17:19   extTemp_0       19.88
     2021-01-19 16:17:19   extTemp_0f      67.78
     2021-01-19 15:54:12   firmware        v1.9.0
     2021-01-19 16:17:19   humidity        47.5
     2021-01-19 16:20:26   network         not connected
     2021-01-19 15:43:04   sensorError     0
     2021-01-19 16:20:26   state           Error
     2021-01-19 16:20:26   temperature     19.88
     2021-01-19 16:11:00   wakeupEvent     sensor
Attributes:
   DbLogExclude .*
   DbLogInclude humidity,temperature,dewpoint
   event-on-change-reading humidity,temperature,dewpoint,battery,extTemp_0,
   icon       temperature_humidity
   interval   0
   model      generic
   room       71 Thermometer,Shelly
   stateFormat T: extTemp_0 °C H: humidity % B: battery
   userReadings dewpoint:extTemp_0.* {urDewpoint($name)},temperature { ReadingsVal("Thermo_DG_DB_Shelly","extTemp_0",0) }

Sieht soweit ganz gut aus. Ich habe MQTT dafür abgestellt und schaue mal ob die Daten weiterhin über dein Modul kommen.

Gruss
  Enno

ZitatWarte bis Morgen 8 Uhr oder nimm die Version ein paar Beiträge oben und spiele sie per Hand ein!

Yep, mit der Version von weiter oben ist die Meldung weg. DANKE! ! !

Die "morgen 8 Uhr"-Version ist also wärmstens zu empfehlen :-)

In der Tabelle werde ich ab morgen noch bei "generic" den Device-Namen anführen, mit dem sich das Gerät meldet, z.B. SHPLG-S für Shelly Plug S. Mit diesem Namen erkenne ich die verschiedenen Geräte und weise ihnen Models zu. Hier wäre interessant, noch die Werte für Thermometer und Flood zu kennen, damit ich sie dokumentieren kann (Sieht man zwar auch am Verbose-Level 4 im Logfile, aber das kann man ja niemandem zumuten).

Sonst noch Wünsche / Ideen?

Zitat von: gvzdus am 19 Januar 2021, 18:36:05Hier wäre interessant, noch die Werte für Thermometer und Flood zu kennen, damit ich sie dokumentieren kann (Sieht man zwar auch am Verbose-Level 4 im Logfile, aber das kann man ja niemandem zumuten)

Flood bei mir SHWT-1
Thermo bei mir SHHT-1

Gruss
  Enno

Danke, die "generic names" sind dann ab morgen:

    "SHWT-1"   => "shelly_flood",
    "SHHT-1"   => "shelly_ht"

Nach Update läufts weiter gut.

Ich habe noch eine Frage zum Autocreate.
Ist es möglich, das nachdem die gewünschten Namen für neue Devices in der Tabelle eingetragen wurden diese dann auch bei Autocreate verwendet werden ?
Momentan habe ich versucht meinen Wunschnamen für das Device einzutragen und dann auf Autocreate gedrückt und es wurde der generische Name verwendet.
Bei Create wird ja der geänderte Name genommen.(habe ich jetzt nicht nochmal probiert)
Damit würde man das Rename nach dem Autocreate sparen.

Wenn Du Dir die Diskussion im CoIoT-Thread (als Vorläufer zum jetztigen Namen "ShellyMonitor" anguckst), siehst Du, dass da etwas Konfusion ist.
"autocreate" war ursprünglich ein Attribut im Sinne des Betriebsmodus von ShellyMonitor. Die Überlegung: Wenn ein Device auftaucht, wird es automatisch unter dem generischen Namen angelegt - wie bei MQTT. Und es greift wiederum auf das autocreate-Modul von Rudi zurück.
"create" kam dann später, zusammen mit der Tabelle, im Sinne eines interaktiven ("Klick") und imperativen Befehls - unabhängig von den autocreate-Einstellungen.

Da ist zugegeben verwirrende Redundanz schon jetzt im Modul, die Dich dazu bringt, in der Tabelle was einzugeben und unten ein Set-Kommando anzuklicken - es hat nichts miteinander zu tun.

Ich würde vorschlagen: "autocreate" wird wieder ein Attribut, und wenn es (aktiv) eingeschaltet wurde, werden die Geräte automatisch generisch angelegt - sonst über die Tabelle mit Klick.

Ich denke dein Vorschlag ist besser als das verwirrende Verhalten, welches jetzt nicht sehr intuitiv ist.
Ich hatte sogar zunächst versucht autocreate auf 1 zu setzen und mich gewundert, das die Devices nicht automatisch erzeugt werden.

Gibt es einen Grund, warum nicht einfach das globale ,,autocreate" genutzt wird?

Daran ist Joachim schuld!! :-)
Joachim hatte im "autocreate"-Modul das autocreate abgeschaltet, und dann beim Klicken nichts bekommen, weil das autocreate im Sande verlief!
Damit sind 30% aller Nutzer gescheitert, und ich habe das Verhalten geändert.

Mal ein Plan:
- "autocreate" wird ein Attribut, macht ggf. autocreate völlig auto über autocreate
- "Create"-Klick (alternativ: "set <name> create <ip> <name>") legt das Gerät über "autocreate" an. Wenn autocreate nicht funktioniert, weil Joachim es abgeschaltet hat: Fehlermeldung.

Ohje, was hab ich da (durch meine "Dummheit") angerichtet... ;)

Gruß, Joachim

ZitatJoachim hatte im "autocreate"-Modul das autocreate abgeschaltet

Auch ich habe grundsätzlich autocreate abgeschaltet. Man kriegt ja sonst irgendwelche Geräte aus der näheren Umgebung angelegt.
Wenn ich ein neues Gerät hinzufügen möchte, schalte ich es kurzzeitig ein.

ZitatAuch ich habe grundsätzlich autocreate abgeschaltet. Man kriegt ja sonst irgendwelche Geräte aus der näheren Umgebung angelegt.

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.

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

Ich habe bei FHEM mit MAX angefangen, und ohne zu wissen, was da passiert, habe ich es als gottgegeben angenommen, dass ein MAX-Gerät bei mir plötzlich auftaucht, einen Sch.-Namen hat, ein FileLog, und in einem Raum ist. Ich habe mich viel später eingelesen, dass ich verhindern kann, dass die Geräte von meinem Nachbarn bei mir auftauchen.

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.

Das alles ist "autocreate", und eigentlich wäre also die autocreate-Logik in Mod_ShellyMonitor konsistent zur sonstigen FHEM-Erfahrung.

Aber andererseits bin ich da einen Schritt weiter Richtung DAU gegangen: 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!". 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?

ZitatDie FHEM-Systemlast duerfte ohne autocreate hoeher sein,

Vielen Dank für die Info - das war mir nicht bewusst.
Da muss man ja auch mal drauf kommen, dass die Systemlast steigt, wenn man eine Funktion abschaltet.
Ich lasse es aber trotzdem ausgeschaltet, da meine ZBox mit FHEM eh unterfordert ist und ich keine Lust habe, mein System jedesmal anzufassen,
wenn irgendein Nachbar sich einen neuen Sensor gekauft hat.

Zitat von: gvzdus am 20 Januar 2021, 13:23:48
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...

Zitat von: rudolfkoenig am 20 Januar 2021, 12:14:07Ich 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"...

Zitat von: gvzdus am 20 Januar 2021, 13:23:48
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).

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

8) 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 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/general_use.template) zu finden ist (das macht zusätzliche Devices für weitere Kanäle und setzt associatedWith entsprechend).

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

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

Zitat von: rudolfkoenig am 20 Januar 2021, 12:14:07
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.   

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

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.

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

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.

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


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

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

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

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

Gruss
  Enno

"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" :-)

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.

ZitatDazu 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

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.

Zitat von: gvzdus am 22 Januar 2021, 07:57:03
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 ;D 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

Eigentlich sind wir damit OT.

Zitatei 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

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

Ich habe ihn seit mehreren Tagen nicht mehr geklickt. Und trotzdem hat er über MQTT sowohl gestern als auch heute seinen Status gemeldet.

LG

pah

Nix gegen MQTT, aber MQTTler stehen halt auf Schwatzen :-)

Shelly Button & Shelly i3 werden mit der nächsten Version (= SVN jetzt, update morgen) optimiert supported.

Optimiert heisst: Die Eigenarten werden etwas umschifft. Konkret sind nicht nur die generischen Namen etwas konkreter ("shelly_i3" / "shelly_button"), sondern in der Betriebsart als Taster des i3 sowie für den Button generell kann man sich vernünftig mit notify o.ä. auf die Events des Readings "inputEvent_0" bzw. "inputEvent_0/1/2" beim i3 hängen.

Diese sollten jetzt bei einem (Mehrfach-)Tastendruck als Event ausgelöst werden. Anders als das normale Verhalten des Shelly-Moduls, was ShellyMonitor auch übernimmt, lösen ja normalerweise nur Änderungen am Reading Events aus. Natürlich ist aber ein kurzer Tastendruck um 23 Uhr auch dann ein neues Ereignis, wenn schon um 22 Uhr die Taste kurz gedrückt wurde. Dass ein neues Ereignis vorliegt, liesse sich ohne den gerade eingebauten Support sonst nur am eventCounter erkennen.

Und weil's ja sonst zu einfach wäre: Ist der ShellyButton im Batteriemodus, schickt er *immer* beim Aufwachen mit einem kurzen Tastendruck (als Beispiel): "EventCounter 1, Ereignis: S". Heisst: Ist das "wakeupEvent" "button", so wird jedes Ereignis weitergeleitet. Aber das alles nur zum Verständnis: Kurzfassung: Es sollte bequem und einfach funktionieren.

*Einen* Bug des Shelly Buttons habe ich aber nicht umschifft: Beim Aufwachen - also im Batteriemodus - schickt der Shelly Button vor Freude gleich 2 - völlig identische Events - identisch bis auf die Sequenz-Nummer. Im Batteriemodus sollte man also darauf gefasst sein, gleich 2 identische Events hintereinander zu bekommen.

Viel Spaß also mit dem i3 und Button!

P.S.:
Wer's genauer wissen will: Hier das Zitat meines Postings im i3-Thread:

Moin,
ich habe jetzt gerade meinen i3 im Zusammenhang mit COAP/CoIoT untersucht. Ich denke, die Implementierung geht dann morgen rein (schreibe ich noch in den ShellyMonitor-Thread), aber out of the box geht es auch schon halbwegs:

Das Folgende gilt jetzt für CoIoT und Shelly-Monitor, aber die Events sind vermutlich für MQTT ähnlich:

Wer wissen will, "ob das Licht an ist", also den Zustand auf der Leitung wissen will, muss (per Hand) in den "Toggle Switch"-Modus wechseln (default ist "Momentary"). Da wird auf dem Reading input_0 / input_1 / input_2 eine 0 oder 1 übertragen. 1 = gemäß Diagram Verbindung zu L.

Im "Momentary"-Modus werden Taster erwartet, und aus der Einschaltfolge "S", "SS", "SSS" oder "L"-Events erzeugt. (1 x kurz, 2 x  kurz, 3 x kurz, 1 x lang). Hier ist nun eine Anpassung in ShellyMonitor gefragt, um vernünftig und einfach darauf Events aufsetzen zu können. Wie (sicherlich) auch bei MQTT, wird ja der Event-Kanal alle 30 Sekunden wiederholt. Daher lässt sich das Auftreten des Events erst aus der Kombination mit "inputEventCnt_0/1/2 erhöht" ableiten. Die Logik muss also sein:

if (inputEventCnt_x > inputEventCnt_x(old)) {
  setze inputEvent_x als readingUpdate
}

Mod_Shelly arbeitet ja normalerweise immer mit readingsBulkUpdateIfChanged - ein Event wird also nur bei einer Änderung generiert. MQTT hingegen immer (?) mit readingsBulkUpdate. Der "MQTTler" müsste als ein "event-on-change" auf den inputEventCnt_x legen, darauf ein notify etc hängen, um dort inputEvent_x als Art des Ereignisses auszulesen.

Der "Mod_Shellyianer" Stand jetzt genauso, aber ich werde das - gemeinsam für den Button - so implementieren, dass man bei Mod_Shelly sich direkt mit dem Notify auf inputEvent_x "hängen" kann.

Hoffe, damit zur Shelly-Forschung beigetragen zu haben - Vollzug melde ich dann im ShellyMonitor-Thread

Ich habe heute mal an meinen Shelly 1PM das Expansion-Board mit den DS18B20-Sensoren angeschlossen. Die entsprechenden Werte ("extTemp_0" / "extTemp_1" / "extTemp_2" plus das Fahrenheit-Pendant) sind bisher, wenn "model" auf "shelly1pm" statt generic stand, der "Nix durchlassen, was pah nicht in die Readings schreiben würde"-Regel zum Opfer gefallen.

Habe ich angepasst, jetzt kommen sie auch bei "model" = "shelly1pm" durch. Außerdem habe ich "Create" in "Define" in der Tabelle umbenannt - das ist mehr "FHEM-Deutsch".

Zitat"Nix durchlassen, was pah nicht in die Readings schreiben würde"-Regel

Ist ja nett - aber aufgestellt habe ich diese Regel nicht.

LG

pah

Stichwort "Shelly Button":

ZitatIch habe ihn seit mehreren Tagen nicht mehr geklickt. Und trotzdem hat er über MQTT sowohl gestern als auch heute seinen Status gemeldet.

Mein Button (aktuelle Firmware) ist definitiv ein Langschläfer. Vorhin das erste Mal seit 3 Tagen geklickt:

   READINGS:
     2021-01-27 16:36:58   battery         90
     2021-01-24 08:43:08   cfgChanged      0
     2021-01-24 08:43:08   charger         0
     2021-01-24 08:43:08   inputEventCnt_0 1
     2021-01-27 16:36:58   inputEvent_0    S
     2021-01-24 16:45:14   network         not connected
     2021-01-24 08:43:08   sensorError     0
     2021-01-24 16:45:14   state           Error
     2021-01-24 08:43:08   wakeupEvent     button

Wäre er zwischendurch aufgewacht, wäre m.E. das wakeupEvent nicht "button" gewesen, und damit nicht seit dem 24.01. unverändert geblieben. Für den Button fällt mir übrigens kein besonderer Verwendungszweck ein, wenn man ohnehin schon andere Protokolle wie Zigbee im Haus hat. Begeistert bin ich hingegen vom Addon-Modul für Shelly 1pm und Co. mit den DS18B20-Sensoren. Habe mich endlich aufraffen können, Vorlauf- und Rücklauftemperatur der Heizung zu erfassen. Die Sensoren einfach in die Schaumisolierung um die Rohre geschoben. Das Bild anbei ist ohne jede glättende Nachbearbeitung:

Ich halte mehr von 1-Wire-Busssystemen, die mehr als nur DS1820 verkraften. Dazu gibt es von mir 12 verschiedene Module.

LG

pah

Moin,

ich habe das Modul und die Shellies bei mir im Netz alle jetzt angepasst, und es sieht gut aus.

Jetzt habe ich noch einen Shelly, der sich in einem anderen, per VPN mit meinem Netz verbundenen Netz befindet. Ich würde diesen Shelly jetzt gerne auch mit in den Monitor hinein bekommen (als Device ist er angelegt und funktioniert auch soweit gut).

Ein set <name> create <ip-des-VPN-Shelly> <ShellyName> ergibt nur ein Provided IP ^192\.168\.2\.37$ did not match any IPs

Ist es überhaupt möglich, dieses Device in den Monitor mit einzubinden?

Gruß, Christoph

Das wird sportlich: Grundsätzlich kann man MultiCast über Netzwerkgrenzen hinwegrouten (deswegen heißt es ja MultiCast), aber das musst Du in der VPN-Konfiguration vorsehen. Terminiert denn das VPN ebenfalls auf dem gleichen Rechner, auf dem auch FHEM läuft? Dann kann es sein, dass Du das ShellyMonitor-Device mit dem Interface-Parameter anlegen musst, bzw. ein zweites MonitorDevice anlegen musst.

Vorschlag:
Erst mit tcpdump überprüfen, ob und auf welchem Interface Du Pakete vom Remote-Shelly siehst. Dann erst den ShellyMonitor entsprechend konfigurieren.

Zitat von: gvzdus am 28 Januar 2021, 20:50:53
Terminiert denn das VPN ebenfalls auf dem gleichen Rechner, auf dem auch FHEM läuft?

Ich habe beide Netze über die beiden vorhandenen Fritzboxen verbunden - für die Zwecke war es bisher vollkommen ausreichend, sogar Fernwartung war darüber einigermaßen machbar ;)

Zitat von: gvzdus am 28 Januar 2021, 20:50:53
Erst mit tcpdump überprüfen, ob und auf welchem Interface Du Pakete vom Remote-Shelly siehst. Dann erst den ShellyMonitor entsprechend konfigurieren.

Hm, das wird dann eine Herausforderung für mich ... soo bewandert bin ich jetzt nicht mit Netzwerk(un-)tiefen ... Mal sehen, ob und was ich da so erreiche ...
edit: ein paar Zeilen Ausgabe:
sudo tcpdump src 192.168.2.37
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
21:03:35.578093 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [S.], seq 555510, ack 1734417956, win 2144, options [mss 520,nop,nop,sackOK], length 0
21:03:35.680769 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [P.], seq 1:537, ack 319, win 1826, length 536: HTTP: HTTP/1.1 200 OK
21:03:35.725857 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [P.], seq 537:1041, ack 319, win 1826, length 504: HTTP
21:03:35.769532 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [F.], seq 1041, ack 319, win 1826, length 0
21:03:35.770125 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [.], ack 320, win 1825, length 0
21:03:40.783461 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [S.], seq 558687, ack 1373581608, win 2144, options [mss 520,nop,nop,sackOK], length 0
21:03:40.886688 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [P.], seq 1:537, ack 319, win 1826, length 536: HTTP: HTTP/1.1 200 OK
21:03:40.975601 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [P.], seq 537:1041, ack 319, win 1826, length 504: HTTP
21:03:41.020137 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [F.], seq 1041, ack 319, win 1826, length 0
21:03:41.020229 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [.], ack 320, win 1825, length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel




Gruß, Christoph

192.168.2.37 ist die Shelly-Kiste über das VPN?
Dann läuft da gegenwärtig kein Multicast über das VPN, denn Du siehst nur die HTTP-Antwortpakete - mutmaßlich auf das Pollen. Wenn Du es damit vergleichst, was Dir die lokalen Shellies schicken, siehst Du den Unterschied. Sowas:

21:44:05.709074 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204
21:44:13.248156 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204
21:44:28.250845 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204


Das ist das, was ShellyMonitor "mitliest".

Wenn es Dir zu komplex mit dem Ändern des VPN vorkommt - oder gar nicht möglich ist, würde ich auf MQTT gehen. Ist vielleicht einfacher.

Moin,

ok, dann werde ich den einen Shelly wahrscheinlich außen vor lassen - so wichtig ist es dann auch wieder nicht ;)

Gruß, Christoph

Leider hat pah den Thread für 36_Shelly geschlossen.
Hat jemand hier einen Tip, wie man jetzt erfährt welche updates von 36_Shelly gemacht wurden.
Ich frage, weil das sich ja auf das Zusammenspiel mit Shellymonitor auswirken kann.

Es gibt einen neuen Thread für das Shelly-Modul:
https://forum.fhem.de/index.php/topic,118446.0.html (https://forum.fhem.de/index.php/topic,118446.0.html)

Kurze Frage:
Kann ich die Button-URL (get ... status), die ich zur sofortigen Meldung von lokalen Schaltungen an FHEM in den Shellys eingetragen habe, rauswerfen,
wenn ich ShellyMonitor verwende?

Grundsätzlich ja, wobei bei Paketverlusten im lokalen Netz auch mal ein Paket unter den Tisch fallen kann. Ich würde einfach mal schätzen: Mit COAP sollte es in 99,9% der Fälle funktionieren, gefühlt immer.

Ich habe heute den ShellyMotion erhalten. Funktioniert, UI nett gemacht.

Bei ShellyMonitor war ein Anpassung erforderlich, weil beim ShellyMotion die CoIoT-Nachricht ein Token enthält - hatte ich bisher nicht berücksichtigt. Die Änderung ist eingecheckt und morgen im regulären Update verfügbar.

Nicht ganz überraschend heißen die beiden Readings "motion" und "vibration" mit 0 und 1. Daneben kommt noch die "luminosity" sowie 2 Werte, die Shelly nicht dokumentiert hat - ich habe nachgefragt, aber noch keine Antwort.

Bad news
Allterco wird das Multicast in künftigen Versionen erst optional machen, und dann aufgeben, wie Dimitar auf Facebook angekündigt hat. Die aktuelle 1.10-FW des Shelly-Motion kann nur noch Unicast, also "Server:IP".

Was bedeutet das?

• Ohne die Multicast-Messages läuft die Auto-Erkennung der Shellys im Netz nicht. "Ich" könnte auf mDNS wechseln, ist so aber noch nicht implementiert
• Das schöne "einfach Devicenamen eingeben und klicken" - Gerät ist da, klappt auch so wie jetzt dann nicht mehr, denn der Server muss im Frontend aktiv konfiguriert werden
• Einer der Vorteile ggü. MQTT ist weg: Die Möglichkeit, redundant auf mehreren FHEM-Instanzen Nachrichten zu empfangen. Allerdings erlaubt die FW des Shelly-Motion, eine Broadcast-Adresse einzugeben (192.168.0.255 z.B.), und dann klappt es wieder mit mehreren Instanzen

Warum?
Um es im Stoiber-Deutsch zu stammeln: Ein gewisser Professor aus Karlsruhe wird breit grinsen: Man hat gemerkt, dass die ganzen Pakete im Netz jetzt mit den batteriegetriebenen Always-On-Wifi-Geräten auf die Akkukapazität gehen.

Was kann man / ich tun?

• mDNS implementieren und darüber Shellys listen
• mindestens eine neue Version herausbringen, die entweder auf Unicast oder Multicast lauscht. Dann wird man vorübergehend zwei Shelly-Monitor-Instanzen brauchen: Eine für Unicast und eine für Multicast
• Bisher wollte ich nicht invasiv sein, also Shellys "konfigurieren". Wenn es so einfach wie jetzt bleiben soll, dann müsste ich aber mindestens wohl den CoIoT-Server oder Broadcast aktiv am Shelly konfigurieren. Dann könnte man auch gleich darüber nachdenken, alternativ anzubieten: Was möchtest Du? MQTT oder CoIot mit ModShelly?

Alles erst mal meine ersten Gedanken... Unten den Screenshots der Settings von FW 1.10beta5 (für diverse Shellys) und FW 1.10 (für ShellyMotion)

Ach, der gewisse Professor aus Karlsruhe ist bei Forschungsanträgen gewohnt, dass wochenlange harte Arbeit für die Katz war.

Willkommen im Club.

LG

pah

Seit dem Update auf 1.10 wird die Firmwareversion nicht mehr korrekt ausgelesen, kann das evtl. am Shellymonitor liegen ?
pah habe ich schon im https://forum.fhem.de/index.php/topic,118446.msg1141122.html#msg1141122 (https://forum.fhem.de/index.php/topic,118446.msg1141122.html#msg1141122) mit weiteren Informationen gefragt.

Ja, ich werde mich heute ransetzen, es wieder zum Laufen zu bringen. Update ist morgen da, ich hänge es auch hier in den Thread.

Habe geguckt. Nein, "ShellyMonitor" ist unschuldig. Man muss mit 1.10 nur beachten, dass CoIoT eingeschaltet ist und auf "mcast" steht - siehe auch mein Screenshot weiter oben vom Release-Candidate. Aber Multicast ist abgekündigt und daher muss ich da ran, allerdings nicht ultimativ heute.

Meine stehen alle auf mcast und sind enabled

Hallo in die Runde.

Wenn ich das hier vorgestellte Tool und die vorherigen Seiten zu diesem Topic richtig verstehe, liefert es bei meinem Shelly1 + Temp Addon die entsprechenden Readings extTemp_0 und extTemp_0f quasi in Echtzeit.
Hab das Tool jetzt auch drei Tage laufen lassen und nun lässige 10.000 Events gehabt. Sind mir ein wenig viele gewesen. Ohne Tool hatte ich die Shellys auf einen Intervall von 60 Sek eingestellt, was aber, auch gemäß Zweck des Tools, ignoriert wird und permanent Daten liefert.

Ohne Tool schickt Shelly mir diese Daten aber eben garnicht. Alternative wäre, wenn ich´s richtig verstehe, wohl den Shelly über MQTT einzubinden.

Gibt es einen Tipp wie ich an die o.g. Readings in größeren Abständen komme? Beispielsweise nur alle 5 Minuten? Denn so schnell ändert sich die Temperatur in meiner Garage eher nicht.

Würde mich freuen wenn sich Jemand kurz äußern würde. Ich bin leider nicht der große Programmierer, sondern eher der Probierer. Mein SmartHome ansich hab ich, auch dank der vielen Beiträge hier im Forum, bisher ganz gut hinbekommen. Aber hier steh ich etwas auf dem Schlauch. Also bitte um Nachsicht.

Im Voraus vielen Dank.

Erst einmal: Ich werde ShellyMonitor absehbar umbauen müssen, da Allterco den CoIoT-Multicast abgekündigt hat. Aber noch betrifft Dich das nicht.

Zur Frage: Wenn es Dir zu viele Events sind, guck' Dir mal in der FHEM-Doku "event-aggregator" an. Damit legst Du fest, wie die Messwerte gemittelt werden und in welcher Frequenz Du ein Event haben willst. Funktioniert prima, und ist genauer als z.B. nur alle 10 Minuten einen Messwert zu ziehen.

Super danke für die schnelle Rückinfo. Werd mir "event-aggregator" anschauen.

Ja, hab ich schon gelesen, dass perspektivisch das Thema CoIoT ansteht. Hoffe du bekommst das hin und stellst es dann auch weiterhin zur Verfügung! Also noch gehts ja auch! Dafür schonmal ein großes Danke!  ;)

Bin ja auch froh das es mit deinem Tool funktioniert. Hätte ja garnicht gedacht, dass sonst die Readings garnicht kommen.

Bis dahin weiterhin maximale Erfolge und Elan!

ZitatHätte ja garnicht gedacht, dass sonst die Readings garnicht kommen.

Wieso? 36_Shelly.pm liest sie doch aus.

Allerdings unter anderem Namen.

LG

pah

Hallo Münster

Evtl könnte für CoIoT die "coiot_update_period" zur Paket-Reduzierung von 15 Sekunden auf höhere Werte geändert werden.

<Shelly-IP>/settings?coiot_update_period=60 oder 300 (Sekunden)

Gruß

Zitat von: Prof. Dr. Peter Henning am 01 April 2021, 06:13:00
Wieso? 36_Shelly.pm liest sie doch aus.

Allerdings unter anderem Namen.

LG

pah

Hab´s nochmal versucht nachzustellen. Scheinbar wurde erst ein Neustart von FHEM erforderlich, dass er die Readings temperature_0 und humidity_0 gemeldet wurden.
Davor wurde garnichts gemeldet. Mit dem ShellyMonitor kamen dann extTemp_0 und extTemp_0f. Aber eben mit für mich zu geringen Intervallen.

Jetzt nach Neustart erkennt er temperature_0 und humidity_0 und meldet diese eben auch im vorgegebenen Intervall.
Also danke für den Anstoss in dieser Richtung.

@RalfRog
Damit brauch ich den Vorschlag von dir nicht mehr anfassen. Aber trotzdem Danke, dass du noch eine Idee bringen konntest. Wäre ich von mir aus, nicht drauf gekommen.

Wo hier Leute mit Temp-Sensor mitlesen: Ich hatte übrigens bisher 2-mal das Problem, dass mein Shelly 1PM "vergaß", dass er externe Sensoren hat. Sie wurden einfach nicht mehr angezeigt: Nicht in der Web-GUI, nicht per CoIoT. Nach einem Reboot waren sie wieder da. Der Fehler ist aber zuletzt vor einem Monat aufgetreten - vielleicht ein Softwarefix? Aber meldet es doch, wenn's bei Euch auch auftritt.

Zum Fortschritt bei Mod_ShellyMonitor:
Gestern habe ich den Feiertag genutzt, um erst mal die Grundstruktur eines mDNS-Sniffers zu schreiben (der Vorläufer von ShellyMonitor war ja auch der "shellysniffer"). Nervig: Wie auch bei CoIoT *scheint* es so zu sein, dass Allterco auch hier nicht sauber für die Batteriegeräte wie den ShellyMotion im mDNS eine TTL setzt, und sich vor Ablauf wieder meldet. Aber immerhin bietet mDNS ggü. CoIoT halt das "AutoDiscovery"-Feature.

Nun denke ich über die Transition nach. Im Standardmodell kann ein Shelly-Modul nur einen Socket lesen. Ich brauche aber:

• den "alten" CoIoT-MCast-Listener
• den "neuen" CoIoT-UniCast-Listener
• einen neuen mDNS-MCast-Listener

Ein mDNS-MCast-Modul ergibt natürlich auch unabhängig von ShellyMonitor Sinn. Aber 3 Module? Naja, ich grübele halt noch.

Hallo
Von meiner Seite auch noch mal ein Danke für das Modul. Ich werd mal hier die Entwicklung weiterverfolgen. Aktuell habe ich "nur" 2 Shelly's (PlugS & 1PM) mit FW1.10 .

Aus meiner jetzigen Sicht hat das Modul einfach den Vorteil die Werte zu erhalten ohne das Device (ggfs. mit User/Passwort) per HTTP häufig abfragen zu müssen. Da reicht dann 1-2 mal täglich.

Gruß Ralf

Nur zur Entwarnung: Wenn Allterco Multicast nicht mehr unterstützt, müssen im Modul etwa 5 Zeilen geändert werden, und im Shelly die IP-Adresse von FHEM explizit angegeben werden. Aber ich möchte halt rechtzeitig eine "schöne" Lösung hinbekommen, die so simpel wie jetzt bleibt.

Zitat von: RalfRog am 03 April 2021, 11:54:42
Hallo
Von meiner Seite auch noch mal ein Danke für das Modul. Ich werd mal hier die Entwicklung weiterverfolgen. Aktuell habe ich "nur" 2 Shelly's (PlugS & 1PM) mit FW1.10 .

Aus meiner jetzigen Sicht hat das Modul einfach den Vorteil die Werte zu erhalten ohne das Device (ggfs. mit User/Passwort) per HTTP häufig abfragen zu müssen. Da reicht dann 1-2 mal täglich.

Gruß Ralf

Sorry, ich verstehe deinen Komentar nicht. Das Shelly-Modul  leistet das doch auch.

Zitat von: Paul
Sorry, ich verstehe deinen Komentar nicht. Das Shelly-Modul  leistet das doch auch.

Ja klar. Natürlich ist das Shelly-Modul prima und macht alles was man braucht (auch hier ein Danke an PAH).

Ich finde es halt spannend (falls coIoT aktiv), dass man die Werte einsammeln kann (und nur die Werte) ohne aktiv HTTP Abfragen zum Shelly zu schicken.
In der Status-Antwort stehen ja ne ganze Reihe Infos die nicht alle paar Minuten durch das Netz müssten.
Immerhin habe ich im tcpdump auf dem PI gesehen, dass User/Passwort nicht im Klartext durchgehen (da fehlt mir allerdings der Hintergrund ob eine Authentifizierung im unverschlüsseltem HTTP überhaupt im Klartext laufen würde).

Moin,
irgendwie läuft es ja auch mit der aktuellsten Firmware weiter...

Man muss zwar inzwischen CoIoT manuell einschalten, und ggf. als Ziel-IP die Broadcast-Adresse eintragen, aber aufgegeben ist CoIot noch nicht.

Ich habe heute den Shelly TRV (Heizkörperthermostat zum Luxuspreis) erhalten, und in 36_ShellyMonitor integriert. Morgen vormittag sollte die neue Version per FHEM-Update verfügbar sein. Wermutstropfen: Die gemessene Temperatur wird nur ohne Nachkommastellen übermittelt.

Ich werde demnächst mal etwas über den TRV schreiben. Das Reading sieht so aus:

Internals:
   CFGFN     
   DEF        192.168.0.18
   DURATION   0
   FUUID      61ce0759-f33f-8d06-314b-a0caab6af0ed2bb1
   INTERVAL   0
   NAME       shelly_trv_60a423d0d846
   NR         497
   SHELLYID   60A423D0D846
   STATE      Error
   TCPIP      192.168.0.18
   TYPE       Shelly
   READINGS:
     2021-12-30 20:29:00   battery         100
     2021-12-30 22:23:03   cfgChanged      2
     2021-12-30 20:24:11   cloud           disabled
     2021-12-30 22:23:03   extTemp_0       20
     2021-12-30 22:17:00   extTemp_0f      69
     2021-12-30 20:24:11   firmware        v2.1.0
     2021-12-30 20:24:09   network         <html>connected to <a href="http://192.168.0.18">192.168.0.18</a></html>
     2021-12-30 20:29:00   sensorError     0
     2021-12-30 20:24:12   state           Error
     2021-12-30 22:17:41   targetTemp      22
     2021-12-30 22:17:41   targetTempF     71
     2021-12-30 20:29:00   valveError      0
     2021-12-30 22:33:01   valvePos        18.22
Attributes:
   interval   0
   model      generic

Zitat von: gvzdus am 30 Dezember 2021, 22:34:06
Moin,
irgendwie läuft es ja auch mit der aktuellsten Firmware weiter...

Man muss zwar inzwischen CoIoT manuell einschalten, und ggf. als Ziel-IP die Broadcast-Adresse eintragen, aber aufgegeben ist CoIot noch nicht.

Freut mich! :)
Auch wenn ich es aktuell nicht mehr nutze(n kann: muss erst herauskriegen, wie ich die Pakete in meinem doch bewusst eingeschränktem Unifi Netzwerk zwischen V-LANs hin und her bekomme / aber leider nicht wirklich hohe Prio: habe nicht wirklich viele Shelly laufen und wenn dann "simple" mittels Shelly-Modul -> reicht mir)

Zitat von: gvzdus am 30 Dezember 2021, 22:34:06
Ich habe heute den Shelly TRV (Heizkörperthermostat zum Luxuspreis) erhalten, und in 36_ShellyMonitor integriert. Morgen vormittag sollte die neue Version per FHEM-Update verfügbar sein. Wermutstropfen: Die gemessene Temperatur wird nur ohne Nachkommastellen übermittelt.

Ich werde demnächst mal etwas über den TRV schreiben. Das Reading sieht so aus:

Auf jeden Fall!! :)

Da bin ich gespannt drauf!
Hab die auch schon bemerkt...

Aber aktuell laufen meine Homematic noch gut (klopf auf Holz ;)  )...
...aber man muss ja schon mal mit Alternativen bereit stehen... 8)

Gruß, Joachim

Zitat von: gvzdus am 30 Dezember 2021, 22:34:06
irgendwie läuft es ja auch mit der aktuellsten Firmware weiter...

Man muss zwar inzwischen CoIoT manuell einschalten, und ggf. als Ziel-IP die Broadcast-Adresse eintragen, aber aufgegeben ist CoIot noch nicht.

Moin,

wenn Du mir jetzt noch verrätst, wo ein Shellyplus1 den Schalter für CoIoT hat ... ich konnte bisher nichts finden. Bei den Gen1-Geräten ist CoIoT doch meist sogar schon eingeschaltet gewesen, zumindest konnte ich sie i.d.R. im Shellymon bereits nach kurzer Zeit sehen als neue Geräte ... oder per shelly-Modul definieren, sobald ich sie ins WLan gebracht hatte ...

Gruß, Christoph

Zitat von: gvzdus am 30 Dezember 2021, 22:34:06
und in 36_ShellyMonitor integriert. Morgen vormittag sollte die neue Version per FHEM-Update verfügbar sein.

Moin,
ich habe nun auch den TRV, der wird aber nicht erkannt (Update von 36_ShellyMonitor ist durchgelaufen). Muss ich anders als bei anderen Shellys noch was anstoßen/einstellen/was auch immer?

Danke und Gruß
Uwe

Hat sich erledigt, hab's gefunden.

Gruß
Uwe

Hallöchen,
ich bin über das Update auf das Modul aufmerksam geworden und hab es fix mal installiert.
Allerdings zeigt mir das Modul mal eben nix an  :-[

Meine etwa 10 Shellies sind alle über MQTT an FHEM angebunden. Sonst habe ich nix in den Shellies eingeschalten.

FHEM läuft in einer VMWare auf meiner Synology, deswegen habe ich das Interface mit angegeben.

Internals:
   DEF        ens3
   FD         10
   FUUID      61d8584f-f33f-0f04-bab6-86bb679734a9b606
   NAME       shellymon
   NOTIFYDEV  global
   NR         714
   NTFY_ORDER 50-shellymon
   STATE      ???
   TYPE       ShellyMonitor
Attributes:


Was muss ich tun, damit die Shellies gelistet werden?

Besten Dank und Grüße aus Leipzig.
//Erik

ZitatWas muss ich tun, damit die Shellies gelistet werden?

Wenn ens3 das korrekte Interface ist dann fallen mir nur noch zwei Dinge ein:

• Alle Anforderungen erfüllt: JSON und multicast perl?
• CoIoT an den Shellies aktiviert?

VG Sebastian

Hallo in die Runde,
CoIOT war nicht aktiviert. Nachdem ich die Funktion aktiviert habe und die Shellie's neu gestartet habe, geht es jetzt.

Vielen Dank für die Hilfe.
//Erik

Hallo,

habe jetzt auch TRV, werden bei mir nicht erkannt, weil ich was nicht finde (https://forum.fhem.de/index.php/topic,117805.msg1197943.html#msg1197943)
@UweH ich bin zu doof und finde es nicht. Bitte um Hilfe. Danke.

LG Peter

@doch nicht zu doofe, hab es auc gefunden

Zitat von: elektrikpe2 am 15 Januar 2022, 21:41:47
Hallo,

habe jetzt auch TRV, werden bei mir nicht erkannt, weil ich was nicht finde (https://forum.fhem.de/index.php/topic,117805.msg1197943.html#msg1197943)
@UweH ich bin zu doof und finde es nicht. Bitte um Hilfe. Danke.

LG Peter

@doch nicht zu doofe, hab es auc gefunden

Und gerade wollte ich Dir antworten... ;)

Aber dann gleich mal eine Frage...seit dem FW-Update auf v2.1.2 vom 15.01. kennt mein TRV quasi nur noch zwei Ventilstellungen, 0 und 100%. Vorher hat das Einregeln IST auf SOLL-Temperatur prima funktioniert, jetzt ist bei 22° Soll und 23° Ist das Ventil immer noch zu 100% geöffnet. Erst wenn ich manuell die Soll-Temperatur unter die Ist-Temperatur bringe, regelt es wieder zurück. Hat diesen Effekt sonst noch jemand? Habe ein Ticket bei Allterco erstellt, mal schauen, was die sagen.

Gruß
Uwe

Hallo,

ich habe mir auch ein TRV zugelegt, da ich annahm, dass es jetzt integriert ist.
leider erkennt mein Shellymonitor das gerät nur als Generic. Damit kann ich nichts anfangen.
Mache ich was falsch, oder ist das TRV noch nicht drin? (Habe alle Updates installiert).

Danke schon mal für die Hilfe im Voraus.  :)

Hi, nein, der TRV wird z.Zt. m.W. von nichts (Shelly, ShellyMonitor, MQTT?) unterstützt.
Wenn Du selber "basteln" willst, sollte am ehesten mit HTTPMOD und der Shelly-API-Doku ein Basic-Support machbar sein.

Über MQTT läuft das Ding prima.

Gruß
Uwe

Hallo UweH,

danke, ich wollte das grad mal unter MQTT einbinden, jedoch gibts für das Shelly TRV kein attr-Template.
Wie hast du das eingebunden?
Die Readings habe ich, jedoch bekomme ich die Settings nicht per setList hin, ich habe schon viel rumprobiert, aber es klappt nicht die Temperatur einzustellen.
Laut Shelly-API Referenz müsste das eigentlich so als setList aussehen:
thermostats_1_target_t_value:slider,4,1,31 shellies/$Name/thermostat/0/command/target_t $EVTPART1

PS.: Ich weiss, das gehört nicht in diesen Thread, Sorry, aber am Einfachsten war es für mich auf UweHs Antwort zu reagieren.  8)

Ein Modul für ShellyMonitor wäre mir auch noch am liebsten, jedoch habe ich mich auch daran versucht und das ist ja nooooch komplizierter...  :o

Auch das Modul kann TRV-Readings lesen, als model generic, ohne set-Befehle. Gleiches gilt für MQTT, da werden auch endlos Readings ohne Template geliefert. Befehle absetzen geht per http. Temperatur einstellen z.B. per
http://<TRV-IP>/thermostat/0?target_t=22

Ventilposition http://<TRV-IP>/thermostat/0?pos=1

Den Befehl in einem notify absetzen würde dann z.B. so aussehen:fhem('{GetFileFromURL("http://<TRV-IP>/thermostat/0?pos=1")}')

Die ganze Befehlsübersicht gibt's hier: https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv-settings-thermostats-0 (https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv-settings-thermostats-0)

Gruß
Uwe

Moin UweH,

herzllichen Dank für deine Unterstützung.
Die Readings habe ich ja schon, nun wollte ich über setList die Set-Befehle hinzufügen, was mir aber nicht gelingt.
Dein Vorschlag die Befehle über http oder https abzusetzen ist eine Möglichkeit, die ich noch nicht in Betracht gezogen habe, da ich gern immer alles schön geordnet haben will. Also wenn eine Gerät für die Kommunikation mqtt nutzt dann ziehe ich es vor auch alles über das eine Protokoll zu machen, ansonsten wird mir das bei über achtzig Geräten zu komplex.  :-\
Ich forsche dann mal weiter, wieso das TRV meine mqtt-Befehle nicht annimmt...
Wenn ich das irgendwann raus habe, könnte man ja die Befehle in das Modul einbauen !?

Gruß
Olli

Hurra, es geht... :D
ich habe jetzt mal mit MQTT-Explorer das Ganze beobachtet und habe nun die Syntax für die Ansteuerung des Shelly TRV mit MQTT gefunden.
Leider war das in der API-Referenz nicht ganz klar beschrieben und in den Foren sind immer irgendwelche Ausdrücke genutzt worden, die Klammern oder Anführungszeichen nutzen.
Das scheint beim Shelly viel einfacher zu sein -> einfach alles Weglassen!  ;)

Um einen Slider für Shelly TRV zur Temperatureinstellung über setList hinzuzufügen einfach folgenden Befehl ausführen:
attr MQTT2_shellytrv_NUMMER setList thermostats_1_target_t_value:slider,4,1,31 shellies/shellytrv-NUMMER/thermostat/0/command/target_t $EVTPART1

Unbedingt auf _ und - achten, da kommt man schnell durcheinander.
Wenn ich dann noch irgendwie rauskriege wie man das als Modul ins ShellyMonitor- oder Shelly-Modul reinbekommt werde ich wieder schreiben.

Bis denn
Olli

ZitatShelly-Modul reinbekommt

Falscher Thread

pah

ZitatFalscher Thread

Sorry, ich wusste nicht, dass man ein weiteres Modul hier nicht erwähnen darf.
Dann lasse ich es halt und werde alleine glücklich.  :P

Prima, das freut uns - macht weniger Arbeit.

pah

Ich nutze das Modul mit einen Shelly Plug-S genau dafür:

Zitat von: gvzdus am 16 Januar 2021, 14:18:47
Dieses Modul wertet Multicast-Messages aus, die jedes Shelly-Gerät i.d.R. alle 30 Sekunden und bei wichtigen Zustandsänderungen im Netzwerk sendet.
Diese Pakete werden für 2 Zwecke verwendet:

• Readings in Geräten, die mit 36_Shelly.pm angelegt wurden, werden aktualisiert. Das Pollen im Shelly-Modul kann daher auf eine sehr niedrige Frequenz gestellt werden - z.B. um Readings wie verfügbare Firmwareupdates anzuzeigen.

Ist das Modul noch kompatibel zum aktuellen "36_Shelly.pm".  Beim PlugS alles ok aber beim 3EM aktualisiert sich nur Voltage.

Gruß Ralf

Den 3EM habe ich nicht. Ich habe damals die Doku von Shelly abgetippt, vielleicht hat sich was geändert. Hilfreich wäre:
a) DEBUG-Log
b) Tcpdump.

Ja, ich bin eigentlich erstaunt, dass ShellyMonitor nach wie vor "aktuell" ist. Die Abkündigung von CoAP scheint Shelly wieder für Gen1 eingestampft zu haben. Ich als Autor nutze es nach wie vor, und ich mag die Kombination aus "Begrenzung auf die wesentlichen Werte" und Cloud-Fähigkeitkeit im Vergleich zu MQTT.
Allerdings wäre der 3EM durchaus ein Gerät, bei dem MQTT nicht falsch ist, da permanent Werte übertragen werden.

Geht mir auch so.
Schicke im Laufe des Tages Daten.

Gruß Ralf

Zitat von: gvzdus am 26 Dezember 2022, 23:27:12
... Hilfreich wäre:
a) DEBUG-Log
b) Tcpdump.

Hallo Daten angehängt:
http://<IP>/status
http://<IP>/cit/d


$ sudo tcpdump -vv -A -i eth0 port 5683

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:24:09.986549 IP (tos 0x0, ttl 128, id 381, offset 0, flags [none], proto UDP (17), length 363)
    aa.bb.cc.dd.5683 > 224.0.1.187.5683: [udp sum ok] UDP, length 335
E..k.}....-.
..\.....3.3.W.=P. ..cit.s....SHEM-3#244CABxxyyzz#2.CX.....{"G":[[0,9103,0],[0,1101,0],[0,4105,0.00],[0,4106,32.2],[0,4107,128.3],[0,4108,226.36],[0,4109,0.01],[0,4110,-0.04],[0,4205,0.00],[0,4206,0.0],[0,4207,0.0],[0,4208,0.10],[0,4209,0.01],[0,4210,0.00],[0,4305,0.00],[0,4306,0.0],[0,4307,0.0],[0,4308,0.08],[0,4309,0.01],[0,4310,0.00],[0,6102,0]]}

--------------------------------------------------------------------------------------------------------------------------------------------------

Verbose 5 vom Modul

2022.12.25 22:51:00.623 4 : Received data from aa.bb.cc.dd
2022.12.25 22:51:00.624 4 : aa.bb.cc.dd: in cache, devices=shelly_3em_haus (size=1)
2022.12.25 22:51:00.625 5 : URI: /cit/s, global_devid = SHEM-3#244CABxxyyzz#2, validity=2253, serial=2
2022.12.25 22:51:00.627 5 : Found device shelly_3em_haus, model shelly3em
2022.12.25 22:51:00.627 5 : cfgChanged = 0
2022.12.25 22:51:00.628 5 : output_0 = 0
2022.12.25 22:51:00.629 5 : power_0 = 0
2022.12.25 22:51:00.630 5 : energy_0 = 3.4
2022.12.25 22:51:00.630 5 : energyReturned_0 = 126.4
2022.12.25 22:51:00.631 5 : voltage_0 = 225.47
2022.12.25 22:51:00.631 5 : current_0 = 0.01
2022.12.25 22:51:00.632 5 : powerFactor_0 = 0.01
2022.12.25 22:51:00.632 5 : power_1 = 0
2022.12.25 22:51:00.633 5 : energy_1 = 0
2022.12.25 22:51:00.633 5 : energyReturned_1 = 0
2022.12.25 22:51:00.634 5 : voltage_1 = 0.1
2022.12.25 22:51:00.634 5 : current_1 = 0.01
2022.12.25 22:51:00.634 5 : powerFactor_1 = 0
2022.12.25 22:51:00.635 5 : power_2 = 0
2022.12.25 22:51:00.636 5 : energy_2 = 0
2022.12.25 22:51:00.636 5 : energyReturned_2 = 0
2022.12.25 22:51:00.636 5 : voltage_2 = 0.09
2022.12.25 22:51:00.637 5 : current_2 = 0.01
2022.12.25 22:51:00.637 5 : powerFactor_2 = 0
2022.12.25 22:51:00.637 5 : overpower_0 = 0


Hoffe das reicht
Gruß Ralf

Edit (Dump kommentiert):
{"G":[
[0,9103,0],
[0,1101,0],
     Power W     Energie Wh     EnergieRet Wh            Volt V        Strom A            pf
[0,4105,0.00],[0,4106,3.4],[0,4107,126.4],[0,4108,225.40],[0,4109,0.01],[0,4110,0.02],
[0,4205,0.00],[0,4206,0.0],[0,4207,0.0],  [0,4208,0.10],  [0,4209,0.01],[0,4210,0.00],
[0,4305,0.00],[0,4306,0.0],[0,4307,0.0],  [0,4308,0.09],  [0,4309,0.01],[0,4310,0.00],
[0,6102,0]]

Okay, ich interpretiere das so: Im DEBUG-Log siehst Du die richtigen Werte, aber sie werden nicht ins Device geschrieben, korrekt?

Dann ist der Grund vermutlich, dass ich in ShellyMonitor nicht das "model" "shelly3em" eingetragen habe. Wenn Du mal mit dem Editor in 36_ShellyMonitor gehst, siehst Du um Zeile 200 die Definitionen, wie viele Kanäle welcher Typ hat. Das wird u.a. dazu verwendet, damit einkanälige Geräte "power" und nicht "power_0" schreiben. Hier gibt es keine Definition von "shelly3em", weil es damals (tm) das nicht im Shelly-Modul gab.

Probiere bitte mal, die Zeile für "shelly3em" einzufügen. Also:

    196 # Copied from 36_Shelly, keep up to date..:
my %shelly_models = (
#(relays,rollers,dimmers,meters)
"generic" => [4,4,4,4],
  "shellygeneric" => [4,4,4,4],
  "shelly1" => [1,0,0,0],
  "shelly3em" => [1,0,0,3],


Ich muss hier mal meinen Kommentar "Keep up to date" beherzigen...

Ja werde ich machen.
Habe gerade auf die aktuelle FW 1.12.1 aktualisiert (kommt noch was mit dem Neutralleiter dazu) und bin gerade dabei vom Testaufbau in den Keller zu verlagern.

Melde mich wenn ich wieder ordentlich testen kann  :)

War mit ein Grund dich anzutriggern  8)

Zitat
Ich muss hier mal meinen Kommentar "Keep up to date" beherzigen...

Sodele das Ding ist im Verteiler und misst nun auf allen drei Phasen.

Im Modul "36_ShellyMonitor.pm" ist eingefügt:
# Copied from 36_Shelly, keep up to date..:
197 my %shelly_models = (
198     #(relays,rollers,dimmers,meters)
199     "generic" => [4,4,4,4],
200     "shellygeneric" => [4,4,4,4],
201     "shelly1" => [1,0,0,0],
202     "shelly1pm" => [1,0,0,1],
203     "shelly2" => [2,1,0,1],
204     "shelly2.5" => [2,1,0,2],
205     "shellyplug" => [1,0,0,1],
206     "shelly4" => [4,0,0,4],
207     "shellyrgbw" => [0,0,4,1],
208     "shellydimmer" => [0,0,1,1],
209     "shellyem" => [1,0,0,2],
210     "shelly3em" => [1,0,0,3],    # Ralf
211     "shellybulb" => [0,0,1,1],
212     );

Mit inaktivem "CoIoT" werden alle 180 durch das Modul "36_Shelly.pm" die Readings (bei Änderungen) aktualisiert. Soweit Ok!

cloud disabled 2022-12-25 21:08:47
energy_0 559.8 2022-12-27 20:23:23
energy_1 952.2 2022-12-27 20:23:23
energy_2 563.8 2022-12-27 20:23:23
firmware v1.12.1 2022-12-27 12:28:04
network connected to 10.20.30.92 2022-12-27 19:12:15
power_0 126.36 2022-12-27 20:23:23
power_1 172.48 2022-12-27 20:23:23
power_2 245.15 2022-12-27 20:23:23
relay off 2022-12-25 21:09:47
relay_0 off 2022-12-25 22:32:32
state OK 2022-12-27 19:13:24
voltage_0 227.21 2022-12-27 20:23:23
voltage_1 226.39 2022-12-27 20:23:23
voltage_2 226.69 2022-12-27 20:23:23


Nun habe ich "CoIoT" aktiviert und die UpdatePeriod von defaut = 15 auf 60 Sekunden erhöht (hat glaube ich keine Auswirkung, bzw. ich weiss nicht wo).
Was fällt auf:

• reading relay wird durch ShellyMonitor aktualisiert, sofort beim Schalten / ohne ShellyMonitor Reading nicht vorhaden
• reading relay_0 wird durch Shelly aktualisiert, beim Poll
• im Pollintervall vom Shelly werden voltage_x (V) und power_x (W) und energy_x (Wh aufsummiert) aktualisiert, entsprechend Meldung http://<IP>/status
• voltage_x und power_x werden anscheinend korrekt durch die CoIoT aktualisiert (aber auch häufiger als 60 sek
• energy_x wird durch CoIoT aktualisiert allerdings mit 2stelligen Werten, wo auch immer das herkommt siehe Ausgabe EventMonitor im Anhang

Lass uns die Vorgehensweise abstimmen.

Gruß Ralf

Edit: Korrektur zu relay_0  muss ne Altlast sein, eventuell wg. attr model, heiss wohl nur relay!

Moin,
vermutlich kennst Du schon die etwas shelly-eigene Einheit "Wattminuten". Die kommt bei vielen Geräten, aber beim Shelly3EM hat Allterco dann offensichtlich ein Erbarmen gehabt und handelsüblichere "Wattstunden" genommen.

Da ich keine Geräte kannte, die Wattminuten senden, war mir nicht aufgefallen, dass ich *immer* umrechne.

Nächster Schritt wäre also, um Zeile 717 die Umrechnung von der Einheit abhängig zu machen:

Zitat717               } elsif ($rtype eq "energy") {
    718                 my $subs = ($shelly_models{$model}[3] ==1) ? "" : "_".$rno;
    719                 readingsBulkUpdateIfChanged($device, "energy" . $subs,
    720                    $defarr->{"unit"} eq "Wmin" ? int($svalue/6)/10 : $svalue);
    721               } elsif ($rtype eq "output") {

Klappt für meine Gen1-Shellys mit Wmin, wird für Dich wohl auch dann die doppelte Umrechnung Wmin -> Wh vermeiden.

Dann bliebe vermutlich als letzte Baustelle "energyReturned" - was ist das überhaupt?

Hallo
Danke ich habe es "gepatched". Faktor 60 hätte man viellleicht auch sehen können  ::)

Klappt!!

Die Returned-Werte fehlen leider (noch) im Shelly-Modul.

Der 3EM misst in beide Richtungen.
Die Power kann dabei je nach Stromflussrichtung negativ werden (vermutlich über den neg. pf berechnet).
Das Gerät summiert zur Trennung Bezug / Einspeisung (z.B. für PV) die positiven Werte als "total" und die negativen Werte als "total_returned" und liefert sie über http://<IP>/status aus.
Die Werte werden aufsummiert und sollen auch nach Stromausfall erhalten bleiben.

Bei Verwendung vom "mqtt" kommt lt. Doku noch energy / returned_energy dazu, die aber nicht persistent sind.
Für CoIot oder die API stehen diese beiden Werte nicht zur Verfügung.

Darüber hinaus speichert das Gerät 4 csv-Dateien mit den minütlichen Energiewerten pro Phase und Gesamt http://<IP>/emeter/{index}/em_data.csv (index =0|1|2|3)
=> wurde ab SW 1.12 verändert auf Energie und Voltage für je drei Phasen, habe daher zurückgerüstet

Inwieweit diese Dinge über die Timer-Werte zu beeinflussen sind weiss ich (noch) nicht.

Beispiel CSV - Wh-Werte immer nur für die eine Minute (müsste man selber für einen längeren Zeitraum addieren).
Date/time UTC,Active energy Wh,Returned energy Wh
2022-12-27 23:00,7.53,0.00
2022-12-27 23:01,7.68,0.00
2022-12-27 23:02,7.76,0.00
2022-12-27 23:03,7.67,0.00
2022-12-27 23:04,7.47,0.00
2022-12-27 23:05,7.48,0.00
2022-12-27 23:06,7.89,0.00
2022-12-27 23:07,7.43,0.00
2022-12-27 23:08,7.28,0.00
2022-12-27 23:09,7.32,0.00
2022-12-27 23:10,7.25,0.00
2022-12-27 23:11,6.64,0.00
2022-12-27 23:12,6.28,0.00
2022-12-27 23:13,6.23,0.00
2022-12-27 23:14,6.25,0.00
2022-12-27 23:15,6.24,0.00
2022-12-27 23:16,8.54,0.00
2022-12-27 23:17,8.58,0.00
2022-12-27 23:18,8.37,0.00
2022-12-27 23:19,8.31,0.00
2022-12-27 23:20,8.29,0.00
2022-12-27 23:21,8.37,0.00
2022-12-27 23:22,8.27,0.00
2022-12-27 23:23,8.23,0.00
2022-12-27 23:24,8.18,0.00
2022-12-27 23:25,6.57,0.00

Gruß Ralf


Edit P.S.   
Frage:  kannst du über den Monitor die Erzeugung der 3 "total_returned" Readings provozieren?

Edit 2

Verbose 5 vom Monitor:
2022.12.28 21:12:21.368 4 : Received data from 10.20.30.92
2022.12.28 21:12:21.370 4 : 10.20.30.92: in cache, devices=shelly_3em_haus (size=1)
2022.12.28 21:12:21.372 5 : URI: /cit/s, global_devid = SHEM-3#244CAB42CE6B#2, validity=2253, serial=7700
2022.12.28 21:12:21.375 5 : Found device shelly_3em_haus, model shelly3em
2022.12.28 21:12:21.377 5 : cfgChanged = 15
2022.12.28 21:12:21.379 5 : output_0 = 0
2022.12.28 21:12:21.381 5 : power_0 = 126.5
2022.12.28 21:12:21.383 5 : energy_0 = 1798.1
2022.12.28 21:12:21.385 5 : energyReturned_0 = 0
2022.12.28 21:12:21.387 5 : voltage_0 = 227.87
2022.12.28 21:12:21.389 5 : current_0 = 0.88
2022.12.28 21:12:21.391 5 : powerFactor_0 = 0.63
2022.12.28 21:12:21.393 5 : power_1 = 102.25
2022.12.28 21:12:21.395 5 : energy_1 = 2336.2
2022.12.28 21:12:21.397 5 : energyReturned_1 = 0
2022.12.28 21:12:21.399 5 : voltage_1 = 228.02
2022.12.28 21:12:21.400 5 : current_1 = 0.65
2022.12.28 21:12:21.402 5 : powerFactor_1 = 0.69
2022.12.28 21:12:21.404 5 : power_2 = 112.81
2022.12.28 21:12:21.406 5 : energy_2 = 3415.6
2022.12.28 21:12:21.408 5 : energyReturned_2 = 0
2022.12.28 21:12:21.410 5 : voltage_2 = 228.09
2022.12.28 21:12:21.411 5 : current_2 = 0.55
2022.12.28 21:12:21.413 5 : powerFactor_2 = 0.9
2022.12.28 21:12:21.415 5 : overpower_0 = 0

So heissen die Werte des Rückgabe JSON (hier Beispiel Phase 0) energy = total / energyReturned = total_returned
http://<IP>/emeter/0
{"power":125.00,"pf":0.62,"current":0.87,"voltage":227.61,"is_valid":true,"total":1804.6,"total_returned":0.0}

Moin, das schaffen wir auch noch:
In Zeile 699 ergänze bitte mal, dass "energyReturned" auch ausgewertet wird:
699           if ($rname =~ /^(power|output|energy|energyReturned|brightness|extTemp)_(.).*/ || $rname =~ /^(roller.*|mode|L-.*|colorTemp)$/) {

Das muss dann im Folgenden auch in 2 Zeilen geändert werden:

    717               } elsif ($rtype =~ /^energy/) {
    718                 my $subs = ($shelly_models{$model}[3] ==1) ? "" : "_".$rno;
    719                 readingsBulkUpdateIfChanged($device, $rtype . $subs,
    720                    $defarr->{"unit"} eq "Wmin" ? int($svalue/6)/10 : $svalue);


(Achtung: 717 und 719 geändert).

Ich glaube, dann haben wir es :-)

 ;D Passt (Screenshot)

Hoffe es gib keine Nebenwirkungen.
Das Polling vom Shelly-Modul ist damit zwar nicht mehr ganz übereinstimmend, aber das Ziel ist ja CoIot einzufangen.
Polling allenfalls alle 6 Stunden.

Was davon bringst Du ins Monitor-Modul?

Gruß Ralf

P.S:
muss jetzt nur bis zum Frühjahr warten, dass mein PV-Balkonmodul genug für Return liefert  :-[

P.S.2

Es gibt noch die Gesamtleistung "total_power": 341.27 (obere JSON Ebene) s.u. damit erübrigt sich ein Usererading, dass die drei Phasen addiert.
Die Frage ist natürlich ob das so in Konzept mit den anderen Shellies passt oder sich zu weit vom ShellyModul entfernt.
{
"wifi_sta": {
},
"cloud": {
},
"mqtt": {
},
"relays": [
],
"emeters": [
],
"total_power": 341.27,
"fs_mounted": true,
"update": {
},
"ram_total": 49440,
"ram_free": 31424,
"fs_size": 233681,
"fs_free": 156875,
"uptime": 86237
}

> Was davon bringst Du ins Monitor-Modul?

Würdest Du von irgendwas abraten?  :)

Die Änderungen sind eingecheckt, also sollten sie ab morgen per Update in FHEM drin sein.
Habe noch einen ganz kurzen Test bei mir gemacht.

Läuft  ;D

Hinweis für Nutzer des Monitors

Beim Shelly Modul (36_ShellyMonitor.pm) geht die Entwicklung weiter (Testversion) -> https://forum.fhem.de/index.php?msg=1271563
Tests laufen noch / Stand 12. April ist noch das bisherige Modul im SVN.

Achtet bei Updates darauf ob die beiden Module zusammenarbeiten.

• FHEM/36_ShellyMonitor.pm (26929 2022-12-29)
• FHEM/36_Shelly.pm (letzte alte Vesion im SupportThread 4.02f / SVN 4.01)

Im Shelly Support Thread wird schon erwähnt, dass die Weiterentwicklung mit dem Monitor zusammenarbeitet.

=> https://forum.fhem.de/index.php?msg=1274631

Edit:    für Gen1 mit CoIoT

Hallo
mit dieser Test-Version https://forum.fhem.de/index.php?msg=1274963 habe ich die Zusammenarbeit (Shelly-Monitor, -Modul) positiv getestet.
Mit eingeschränkter Modelvielfalt: PlugS, 1PM, 3EM

Gruß Ralf

Ich lese mit, und wenn es was zu verbessern gibt, mache ich das.
"Historisch" wusste es ShellyMonitor halt immer aktueller als das Shelly-Modul, deswegen schreibt das Modul alles, was es mitbekommt.

Die eingeschränkte Vielfalt betraf meinen Zoo ;)

Aktuell meldet der Monitor
Identified Devices
IP           Name         Model   
11.12.13.10  Shelly_Plug  shellyplug, n.s.   
11.12.13.11  S1PM         shelly1pm, n.s.   
11.12.13.12  S3EM         shelly3em, n.s.   
n.s. = not supported by Mod_Shelly
Ist die n.s. Meldung so richtig?

Schon das "alte" Mod_Shelly 4.02f kennt die drei Typen.

Ok macht sicher Sinn zu warten bis Starkstrombasteler offiziell eincheckt.

Der ist einfach:
Was "ich" (ShellyMonitor) mache:
<code>
  LoadModule "Shelly";
  my $fn = $modules{"Shelly"}{"AttrList"};
  if($fn && $fn=~/ model:([^ ]+)( |$)/) {
    map { $shelly_models_by_mod_shelly{$_} = 1 } split (/,/, $1);
    Log3 $hash->{NAME}, 2, "Shelly-Module loaded supports models: " . join(',', keys %shelly_models_by_mod_shelly);
  }
</code>

Früher begann die Liste mit "verbose model:", jetzt steht "model" ganz vorne. Und ich suche nach "<space>model".
Nimm' einfach erst mal das Space weg, also:
<code>
  if($fn && $fn=~/model:([^ ]+)( |$)/) {
</code>

Wie weit ich nachziehe und was pah sagt, muss ich mal schauen. Ich finde es toll, dass jemand am Shelly-Modul entwickelt und auch, dass pah das zulässt. Aber die Anpassungen der Readings-Namen finde ich einen kompletten Holzweg. Es ist schon besch... genug, dass z.B. "Leistung" nicht überall "power" in FHEM als Reading heisst, sondern unterschiedliche Devices unterschiedliche Namen benutzen. Hier noch einzudeutschen, oder im Englischen Uppercase einzuführen, ist m.E. falsch. Genauso finde ich grundfalsch, wenn Reading-Namen sich ändern, je nachdem ob man Mod_Shelly oder MQTT benutzt. Da sollte jeder hin- und herwechseln können, wie er mag.

Jo wech  :)  In der 4.02f mit dem Monitor passt es noch.

Starkstrombastler fehlt bei der Weiterentwicklung eventuell der ein oder andere Zusammenhang - aber PAH hatte sich ja positiv geäußert.

Zitat von: Prof. Dr. Peter Henning am 31 Januar 2023, 15:52:20...
Genau das war der Grund, warum ich es nicht mehr machen konnte. Danke für die hineingesteckte Arbeit, beim Testen helfe ich gerne wieder mit.
...

Ich sehe es jetzt auch wo die Read.-Updates vom Monitor reinfliegen  ::)

Zitat von: gvzdus am 06 Mai 2023, 21:45:23...
Aber die Anpassungen der Readings-Namen finde ich einen kompletten Holzweg. Es ist schon besch... genug, dass z.B. "Leistung" nicht überall "power" in FHEM als Reading heisst, sondern unterschiedliche Devices unterschiedliche Namen benutzen. Hier noch einzudeutschen, oder im Englischen Uppercase einzuführen, ist m.E. falsch.
...

War mir nicht aufgefallen. Ja stimmt besch...


Kommt das energyReturned von meinem Vorschlag Anfang des Jahres (neben current)? Ich befürchte!
Das hatte ich mir ja ins Shelly-Modul von PAH selber reingepatched um die Register zur Verfügung zu haben - über Namensgebung hatte nicht nachgedacht.

Starkstrombastler hat die Einspeisewerte analog zum Shelly (total_returned_x) energy_returned_x genannt. Wäre wohl stimmiger.

Gruß Ralf

Hi,  leider wird ein Shelly 1pm plus nicht erkannt.

Oder wie wird die Liste aktualisiert?

Der Monitor geht nur mit Gen1 (ohne Plus) und im Shelly muss CoIot aktiviert sein.

Damit wertet der Monitor die Meldungen aus, die der Shelly per UDP ins LAN schickt.
Gruß Ralf

Hallo gvzdus

Ich will nicht lange die Hintergrundgeschichte erklären - besteht für den Shelly 1PM (auch einen 1er) die Möglichkeit die Readings
input_0
inputEventCnt_0
inputEvent_0mit dem Monitor zu setzen?


Aktuell habe ich in der Garage einen Shelly 1PM zum Schalten und Messen. Readings:
power
energy
relay

Über den Eingang SW könnte er neben der Softwaresteuerung auch per Schalter An/Aus geschaltet werden.
Es gibt die Einstellung "BUTTON TYPE --> Detached Switch" ("btn_type":"detached") um den Eingang SW unabhängig von Relais zu nutzen.

Die Daten stellt er im Status per "inputs":[{"input":1,"event":"","event_cnt":2}] zur Verfügung und in
CoIot über die ID's 2101,2102,2103 zur Verfügung. Der Monitor kennt die Parameter ja auch schon.
ip/cit/d
{
"blk":[
{"I":1,"D":"relay_0"},
{"I":2,"D":"sensor_0"},
{"I":3,"D":"sensor_1"},
{"I":4,"D":"sensor_2"},
{"I":5,"D":"device"}],
"sen":[
{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":5},
{"I":1101,"T":"S","D":"output","R":"0/1","L":1},
{"I":2101,"T":"S","D":"input","R":"0/1","L":1},
{"I":2102,"T":"EV","D":"inputEvent","R":["S/L",""],"L":1},
{"I":2103,"T":"EVC","D":"inputEventCnt","R":"U16","L":1},
{"I":4101,"T":"P","D":"power","U":"W","R":["0/3500","-1"],"L":1},
{"I":4103,"T":"E","D":"energy","U":"Wmin","R":["U32","-1"],"L":1},
.....
{"I":3117,"T":"S","D":"extInput","R":"0/1","L":2}]
}

Meldung per UDP
{
"G":[
[0,9103,6],
[0,1101,1],
[0,2101,0],
[0,2102,""],
[0,2103,0],
[0,4101,201.92],
[0,4103,1323422],
[0,6102,0],
[0,6109,0.00],
[0,3104,54.39],
[0,3105,129.90],
[0,6101,0]]
}

==> Beim Model "generic" bzw. ohne Model-Attribut gibt's die Readings (input*_0), die vom Monitor ohne Pollen zeitnah aktualisiert werden.

Können die Readings vom Monitor auch für die Modelle 1PM und 1 zur Verfügung gestellt werden?
(Meinen aktuell Workaround mit zweitem Device per JsonMod in kurzen Intervallen auf input.* zu pollen könnte man sich dann schenken)

Gruß Ralf

Edit: Das habe ich auf meinem Livesystem mit der "alten" 4.02f

Hallo gvzdus, zur Info

Habe von Starkstrombastler erfahren, dass die Auswertung des SW-Eingangs  per Attribut "showinputs" steuerbar im "neuen" Modul drin ist.
Die Readings heissen da für Shelly1/PM "button & event_cnt". Habe es mal auf meiner Testinstallation eingestellt.

Der Monitor bedient sie nicht.
Kann das auch nicht einschätzen, da ich kein Gefühl dafür habe wie du die Kopplung hinsichtlich der zu aktualisierenden Reading genau realisierst.

Gruß Ralf

hi.
arbeitet fein, Shelly Plug S sofort eingebunden.

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

Hallo Torsten
Da bist du hier (mit MQTT) beim Shelly Monitor völlig falsch.
Der Monitor liest die per UDP versendeten Daten des COIOT Protokolls der GEN1 Geräte.
Er stellt die Daten dann im Shelly Modul zur Verfügung.
Vorteil man muss nicht pollen, da die Shellies die Daten bei Wertänderungen selbständig versenden.

Verschieb den Beitrag mal besser nach MQTT

Zitat von: RalfRog am 03 August 2023, 18:28:36Verschieb den Beitrag mal besser nach MQTT

Nicht noch einen Doppelpost bitte, Antwort siehe hier....: https://forum.fhem.de/index.php?topic=106986.msg1283288#msg1283288

Ok habe natürlich nicht geguckt ob das schon woanders rumgeistert.

... quasi gleichzeitig  ???

Zitat von: RalfRog am 03 August 2023, 18:33:52Ok habe natürlich nicht geguckt ob das schon woanders rumgeistert.

Kein Ding, bei einem erfahrenem User mit <9 Jahren Zugehörigkeit wie Thoffi1978 braucht man auch nicht mit solchen Netiquette-Verstößen zu rechnen....