39_CoIoT - Modul zur Interpretation der Multicast-Updates von Shellys

Prof. Dr. Peter Henning · 10 Januar 2021, 12:45:18

Und wie wäre es mit 36_ShellyMonitor?

Dann wären sie im Listing direkt hintereinander.

LG

pah

gvzdus · 10 Januar 2021, 12:48:44

Auch gut!
Zum ersten, zum Zweiten, habemus papam?

rudolfkoenig · 10 Januar 2021, 13:51:00

ZitatWas ist unethisch daran, einfach die "CommandAttr"s direkt hinterherzuwerfen, anstatt sie wie von Dir vorgeschlagen mit "PrioQueue_add() oder InternalTimer(0,...)" zu definieren?

Nichts, funktioniert in der ParseFn Variante aber nicht.
Da ParseFn der ueberwiegende Anwendungsfall ist, habe ich ihn hauptsaechlich im Fokus.

gvzdus · 10 Januar 2021, 21:50:05

Ich wäre jetzt eigentlich so weit: Expiren abgeschalteter Shellys ist auch implementiert und getestet, alles umbenannt auf 36_ShellyMonitor, Doku vervollständigt.

Ein sattes Stündchen habe ich aber jetzt mit einem anderen FHEM/Perl-Problemchen verballert und möchte nochmal fragen:

Ich würde gerne aus dem 36_Shelly-Modul den Hash der unterstützten Shelly-Modelle importieren. Der sieht so aus:

Code Auswählen


...
package main;
...
my %shelly_models = (
    #(relays,rollers,dimmers,meters)
    "shellyid" => [0,0,0,0],
    "shelly1" => [1,0,0,0],
...

Erstens habe ich die Tabelle z.Zt. "per Hand" kopiert, zum anderen würde der Import mir erlauben, zu wissen, was das aktuell vom Nutzer verwendete Shelly-Modul kann (und was nicht).

Ist bereits ein Shelly-Gerät da, ist %shelly_models auch für mich sichtbar. Aber der Sinn ist ja, dass der Nutzer mit 0 definierten Shellys-Geräten anfangen kann. Dann ist "%shelly_models" - wenn aus dem Shelly-Modul importiert - nicht definiert. Versuche, in der ShellyMonitor_Initialize-Funktion ein "require <pfad>36_Shelly.pm" oder "LoadModule ("Shelly")" einzuschleifen, haben auch nicht gefruchtet.
Gibt es einen wenigstens mittelsauberen Weg, erst 36_Shelly seine Variablen definieren zu lassen - auch ohne Geräte - bevor ShellyMonitor mit der Arbeit loslegt?

rudolfkoenig · 11 Januar 2021, 10:05:08

Meines Wissens sind per "my" definierte Variablen aus anderen Dateien nicht nutzbar.

gvzdus · 11 Januar 2021, 11:17:29

Ich hätte ja nicht gedacht, dass *ich* irgendwie *Dein* Perl-Wissen erschüttern kann, aber:

Wie viele Autoren verwenden pah und ich "package main" im Modul.

Deklariere ich nicht:

Code Auswählen

use vars qw{%attr %defs %shelly_models};

in meinem Modul, so gibt es beim Laden an die Backe:

Code Auswählen

Global symbol "%shelly_models" requires explicit package name (did you forget to declare "my %shelly_models"?) at ./FHEM/36_ShellyMonitor.pm line 608, <$fh> line 56.

Wenn ich es so deklariere, und mir in der Funktion ShellyMonitor_detailFn:

Code Auswählen


sub ShellyMonitor_detailFn($$$) {
....
  $nstate .= "<tr><td>Shelly_models: " . (%shelly_models ? "yes" :"no") ."</td></tr>";

den Status definiert / nicht definiert anzeigen lasse, so kommt - sofern keine Shellys definiert sind, initial ein "no", und sobald ich den ersten Shelly angelegt habe ein "yes".

Ich habe nun versucht, das Initialisieren von Mod_Shelly zu erzwingen, indem ich:

Code Auswählen

sub ShellyMonitor_Initialize($)
{
  my ($hash) = @_;

  require "$attr{global}{modpath}/FHEM/36_Shelly.pm";

wie auch

Code Auswählen

sub ShellyMonitor_Initialize($)
{
  my ($hash) = @_;

  LoadModule ("Shelly");

probiere - aber beides klappt nicht. Gibt es einen sauberen Weg, zu sagen: "Bevor ein Gerät mit meinem Modul angelegt wird, ist bitte erst Modul xy auch ohne definiertes Gerät einmal initialisiert?"

gvzdus · 12 Januar 2021, 19:16:26

Ich vermute, dass eher das Aufrufen des Hashes dann irgendwie für seine Definition gesorgt hat.

Ich habe den Import der unterstützten Modelle jetzt so gelöst:

Code Auswählen

  # Check which models are available in Mod_Shelly
  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);
  }

Damit bin ich jetzt im Wesentlichen durch. Ich stimme mich jetzt noch mit pah ab, ob wir zusammen eine Version launchen oder ich einzeln vorgehe.

Prof. Dr. Peter Henning · 12 Januar 2021, 19:41:07

Machen wir gerne zusammen - ich bin aber in den beiden nächsten Tagen "Land unter". Freitag.

LG

pah

gvzdus · 12 Januar 2021, 19:59:35

Okay!

Anbei für die interessierte Allgemeinheit der aktuelle Stand:

Das Viech heisst jetzt 36_ShellyMonitor
Die "model" von Mod_Shelly werden importiert. Vom Monitor erkannte Devices ohne korrespondierendes Modell in Mod_Shelly werden mit dem Zusatz und Erläuterung "n.s. = not supported" angezeigt. Legt man diese Devices an, werden sie entweder "shellyid" als Model (falls in Mod_Shelly so bekannt), oder sonst ganz ohne Model angelegt
Wenn ShellyMonitor auch nicht weiß, was das ist: Dann wird als Model generic angezeigt
Ich habe noch einen Typo gefunden (bzw.: denke es), warum die ShellyFloods, die Tim getestet hat, nicht mit Werten befüllt werden.

MadMax-FHEM · 12 Januar 2021, 20:14:32

Was ein "Glück", gerade sind meine "Test-Shelly" gekommen

Brauch ich nur noch etwas Zeit...
...evtl. morgen...

EDIT: ich hab's dann doch schon mal in Betrieb genommen

Allerdings aktuell nur mit meinem Shelly1 -> ist in der Liste

Ich drücke dann man "create"

/ Die Shelly 1L sind dann morgen dran / Dann folgt noch ein Shelly RGB2 (weiß aber nicht wann der kommt)

EDIT: bei Klick auf "Create" passiert nichts... Soll das so?
Das was im Log steht mit verbose 5 (wobei ich da nicht sicher bin, ob das zum "Create" gehört oder auch Meldungen [teilweise] ohne kommen)

Code Auswählen


2021.01.12 20:29:50 1: AutoCreate called for IP 192.168.1.146, ip2devices=1
2021.01.12 20:29:50 3: Please define shelly_1_98f4abf2883b first
2021.01.12 20:29:50 3: Please define shelly_1_98f4abf2883b first
2021.01.12 20:29:50 3: Please define shelly_1_98f4abf2883b first
2021.01.12 20:29:51 5: Received data from 192.168.1.146
2021.01.12 20:29:51 5: 192.168.1.146: in cache, devices=shelly_1_98f4abf2883b (size=1)
2021.01.12 20:29:51 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#2, validity=3840, serial=12
2021.01.12 20:29:51 5: cfgChanged = 0
2021.01.12 20:29:51 5: output_0 = 1
2021.01.12 20:29:51 5: input_0 = 0
2021.01.12 20:29:51 5: inputEvent_0 = 
2021.01.12 20:29:51 5: inputEventCnt_0 = 0

EDIT: bei set ShellyMonitor autocreate MyShelly 192.168.1.146 kommt:
Provided IP MyShelly did not match any IPs

Oder verstehe ich da was falsch?

Sorry, dass ich gleich mit Fragen/Problemen daher komme...

EDIT: ein set ShellyMonitor shelly_1_98f4abf2883b liefert dasselbe Ergebnis (ist IP nicht optional?)

EDIT: so ich hab mal alles was mir so eingefallen ist bzgl. "autocreate" aber es kommt immer diese Meldung... $:-\$
Dass er bereits in ein anderen System integriert ist sollte ja nicht stören? Zumindest war das "alte Modul" davon "unbeeindruckt"...

EDIT: leider muss ich wohl demnächst mein Testsystem mal neu aufsetzen oder zumindest rauskriegen warum mein HMUART wohl seit 09.12. (vermutlich ein OS-Update oder "Zufall" und defekt) nicht mehr tut... $:-\$

Gruß, Joachim

gvzdus · 12 Januar 2021, 21:37:04

Danke für das Feedback! Da muss ich morgen noch mal schauen - ich hatte bisher den Bug drin, dass der Klick auf ein Device mit 192.168.0.5 auch Geräte mit 192.168.0.51 etc. anlegte. Das habe ich wohl verschlimmbessert.

MadMax-FHEM · 12 Januar 2021, 21:40:36

Zitat von: gvzdus am 12 Januar 2021, 21:37:04
Danke für das Feedback! Da muss ich morgen noch mal schauen - ich hatte bisher den Bug drin, dass der Klick auf ein Device mit 192.168.0.5 auch Geräte mit 192.168.0.51 etc. anlegte. Das habe ich wohl verschlimmbessert.

~~Scheint so~~

Keine Eile...
...ich hab (wie geschrieben) grad auch noch andere "Probleme"...

Aber es ist zum Glück nur das Testsystem...

Hat das mit dem HMUART keine wirklich hohe Prio aber "nervt"...

Wenn was da ist kann ich ja wieder testen...
...vielleicht dann schon mit mehreren Shelly

Viel Erfolg, Joachim

gvzdus · 12 Januar 2021, 23:38:19

So, doch noch etwas früh für das Bett gewesen

Zum Einfacheren:
Die Dokumentation war falsch, da stand "set autocreate name ip-pattern". Richtig wäre "set name autocreate ip-pattern". Du kannst keinen Wunschnamen angeben. Mit name war der ShellyMonitor-Device-Name gemeint. Er hat folglich Deinen Namen als IP-Pattern genommen. Okay -> Doku ist gefixt, Fehlermeldung muss noch kommen.

Zum Kniffeligeren:
Warum passiert nix beim Klick? Weiß ich nicht. Die Logzeilen sind an der Stelle so engmaschig, das klar ist: Das Gerät wurde von autocreate nicht angelegt. Die Code-Zeilen:

Code Auswählen

   
    Log3 $name, 1, "AutoCreate called for IP $ip, ip2devices=" . scalar @{$ip2devices};
    my $dname = $device->{name};
    my $model = $device->{model};
    my $mode = $device->{mode};
    my $r = DoTrigger("global", "UNDEFINED $dname Shelly $ip");
    Log3 $name, 1, "AutoCreating $dname returned $r" if ($r);
    if (defined $shelly_models_by_mod_shelly{$model}) {
      CommandAttr ( undef, $dname . ' model ' . $model);

Er loggt also noch: "Ja, ich werde jetzt anlegen". Dann wird AutoCreate angeschubst, aber bei CommandAttr ist das Device nicht da.
Bitte gucke doch mal, wie Du autocreate konfiguriert hast. Mit der Default-FHEM-Config klappt es, und vermutlich hast Du genau da - wegen Deiner vielen Arbeit sonst in dem Bereich dort - was geändert.

Mein TODO: Prüfen, ob das Device auch angelegt wurde und eine Fehlermeldung liefern.
Ich hoffe mal, dass Deine autocreate-Config exotisch ist. Vielleicht ist aber autocreate doch nicht das Richtige, weil Du ja bewusst einen Klick durchführst? Ich fand Rudis Vorschlag eigentlich bestechend, und kenne es so ja auch. Hatte es immer als irgendwie selbstverständlich angenommen, dass ein neues Device ein FileLog hat und in "seinem" Room auftaucht.

MadMax-FHEM · 13 Januar 2021, 00:05:30

Leider: autocreate ist "Standard" bzw. nie (bewusst) von mir geändert und irgendwann zwischen 2014 und 2016 angelegt (oder war schon immer "einfach da") und dann immer nur: Update, Umzug, Restore, usw...
EDIT: OHJE!!!!! ENTSCHULDIGUNG!!!!! MEIN FEHLER!!! Klar der (neue) Plan ist ja autocreate zu nutzen

Äh, ich habe autocreate eigentlich immer aus... Und schalte es nur ein, wenn ich was anlerne... -> also jetzt...

Ich hoffe du kannst mir diesen dummen, dummen "Fehler" verzeihen!!!

Ich nehme alles zurück: Klick auf "Create" legt den Shelly an wie zuvor (coiot) auch, inkl. Stecken in room=Shelly und passendes FileLog-Device

Das mit ohne Name, also nur set ShellyMonitor IP hab ich (glaub ich) auch probiert.
Bzw. alles was mir so eingefallen ist...
EDIT: aber halt eben auch mit deaktiviertem autocreate... $:-\$

EDIT: gerade noch mal getestet. Also set ShellyMonitor autocreate 192.168.1.146 -> pasiert genau nix. Also genauso wie beim Klick auf "Create"

Oder hattest du eine neue Version abgelegt? Ich hab immer noch die, die ich da mal runtergeladen habe... Also die erste 36_ShellyMonitor...

Gruß, Joachim

gvzdus · 13 Januar 2021, 09:10:35

Hmmh, aber was lernen wir jetzt daraus, jenseits: "Ich sollte Fehlermeldungen implementieren"?

Optionen:

autocreate wird automatisch aufgerufen - FHEM verhält sich eben - auch wenn es ungewohnt ist - mit ShellyMonitor auch für Shellys "autokreierend". In der Webansicht werden undefinierte Geräte zu einem Inputfeld, wo man den Namen 'verbessern' kann, und der Klick auf 'OK' ist dann "imperativ" statt über autocreate
Man lässt es, wie es ist; und die Fehlermeldung beim Klick geht Richtung "guck doch mal nach Deinem AutoCreate"-Device

Meinungen?