FHEM Forum

Moin, mein erster vierter Wurf eines Moduls, um das CoIoT-Protokoll der Shellys zu interpretieren und die Readings von Geräten, die über das Shelly-Modul verwaltet werden, zu aktualisieren.
Sprich: Anstatt das Polling-Intervall bei Mod_Shelly niedrig zu drehen oder HTTP-Befehle in den Shellys zu setzen, kommen Aktualisierungen regelmäßig und vor allem bei Änderungen.

a) vor der Installation und danach die CPU-Last überprüfen, die Shellys sind sehr geschwätzig
b) Getestet mit Shelly Plug S, Dimmer 2, Shelly 2.5 in Relay- und Roller-Modus, sowie Shelly 4.

Wer weitere Geräte hinzufügen möchte:

• "verbose 5" einschalten, um im Logfile zu gucken, was an Readings reinkommt
• Code in Zeile 472 ff. erweitern, um die Readings im Shelly-Device zu setzen

Anleitung:

• Modul in FHEM/ - Verzeichnis kopieren
• FHEM restarten
• "define coiot COIOT", oder "define coiot COIOT auto" für Start mit AutoCreate für neue ShellyDevices
• Falls nicht nach ein paar Sekunden das Geschnatter im Status ersichtlich ist: Device wieder löschen und mit Interface-Angabe neu setzen

Keine Garantie für irgendwas, aber viel Spaß!

Du brauchst keine Prototypen, z.B. hier:
sub MCast_Open($$) {

und dann machst du:
return MCast_Open($hash, $dev);

use POSIX qw{strftime};
ist super, allerdings durch use POSIX in fhem.pl hast du das sowieso schon (keine Kritik an dir).

package main;
Mach doch gleich ein eigenes Package.

my @a = split("[ \t][ \t]*", $def);
Nimm lieber parseParams() (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#parseParams)

Die Behandlung von IO::Socket::Multicast finde ich ganz gut, aber das solltest du für JSON auch noch machen, das ist ja auch kein Core-Module.

Statt $! verwende ich inzwischen eigentlich immer $^E (liefert unter MacPerl, W32 und anderen eher exotischen OS aussagekräftigere Fehlermeldungen).

Bis auf den Tipp mit dem package und den Prototypen habe ich Deine Empfehlungen umgesetzt.

"Alpha 0.2" (siehe erster Beitrag) kann jetzt auch einen ersten Wurf von AutoCreation:
FHEM-Raspi an die Schwiegermutter schicken, zusätzlich zum "define coiot COIOT" der Schwiegermutter sagen, dass sie "autoCreate" auf "Shelly" stellen soll, und dann sieht sie kurz danach alle Geräte unter "Everything" mit richtigem "mode" und "model".

Getestet:

• Shelly Plug S
• Shelly 2.5
• Shelly 4
• Shelly 1PM
• Shelly Dimmer 2

Weitere Geräte sollten recht einfach im Code unter %DEVID_MODEL und %DEVID_PREFIX einzutragen sein.

Guten Morgen, im Anhang eine neue Version zum Testen.

Enthält, wie angekündigt, das INTERNAL SHELLYID.

Außerdem habe ich einen neuen Typ eingeführt, mit dem fiktiven Namen shellyid. Dieser Typ kennt keine Aktoren und keine Leistungsmessung, sondern ist einfach zunächst leer und könnte entsprechende Readings (z.B. von Sensoren) bekommen.

Wenn also ein Paket mit dem CoIOT-Protokoll eintrifft, müsste Folgendes passieren:

1. Abfrage, ob bereits ein device mit dieser Shelly-ID existiert. Dafür muss der gesamte Device-Hash durchlaufen werden, und alle Devices vom Typ Shelly bzw. MQTT2-Device auf die ShellyID getestet werden.
2.Wenn nicht, wird es entweder als Shelly-Device mit model=shellyid angelegt, oder als nacktes MQTT-Device.
3.Wenn per Broadcast der Typ des Devices empfangen wurde, kann man model auf einen anderen Wert setzen - oder dem MQTT2-Device ein attrTemplate verpassen.
4. Das CoIoT-Modul hätte dann also eine ähnliche Rolle wie z.B. ein CUL-Device: Es würde auf einlaufende Broadcasts warten und diese an existierende Shelly-Devices dispatchen. Und zwar idealerweise unabhängig davon, ob diese über MQTT oder über 36_Shelly eingebunden wurden. Wobei sich mir die Frage stellt, wie stark die Belastung von FHEM zunimmt, wenn man im Haus ein Dutzend Shelly-Devices hat.

Bitte klären: Wird die Geschwätzigkeit via CoIoT abgestellt, wenn man in den Shelly-Oberfläche unter Settings die Option "Make discoverable" abwählt?

Wie Du das machst, will ich Dir nicht vorschreiben. Nachstehend ein Stück Code aus dem OWX-Modul, in dem das für alle gefundenen Devices auf dem 1-Wire-Bus durchgeführt wird.

LG

pah
 
#-- Check against all existing devices 
    foreach my $fhem_dev (sort keys %main::defs) {
      #-- skip if busmaster
      # next if( $hash->{NAME} eq $main::defs{$fhem_dev}{NAME} );
      #-- all OW types start with OW
      next if( !defined($main::defs{$fhem_dev}{TYPE}));
      next if( substr($main::defs{$fhem_dev}{TYPE},0,2) ne "OW");  (Müsste hier durch Shelly bzw. MQTT2 ersetzt werden)
      my $id_fhem = substr($main::defs{$fhem_dev}{ROM_ID},0,15); (Müsste hier durch die Shelly-ID ersetzt werden=
     
...
    }


   #-- device unknown, autocreate
    }else{
    #-- example code for checking global autocreate - do we want this ?
    #foreach my $d (keys %defs) {
    #next if($defs{$d}{TYPE} ne "autocreate");
    #return undef if(AttrVal($defs{$d}{NAME},"disable",undef));
      $acname = sprintf "OWX_%s_%s",$owx_f,$owx_rnf;
      #Log3 $name, 1, "to define $acname $acstring $owx_rnf";

    Hier die eigentliche Definition als FHEM-Device

      $res = CommandDefine(undef,"$acname $acstring $owx_rnf");
      if($res) {
        $ret.= "OWX_Discover: Error autocreating device with $acname $acstring $owx_rnf: $res\n";
      } else{
        select(undef,undef,undef,0.01);
        push(@owx_names,$acname);
        $main::defs{$acname}{PRESENT}=1;
        #-- THIS IODev, default room (model is set in the device module)
        CommandAttr (undef,"$acname IODev $hash->{NAME}");
        CommandAttr (undef,"$acname room OWX");
        #-- replace the ROM ID by the proper value
        $main::defs{$acname}{ROM_ID}=$owx_dev;    (Hier durch Shelly-ID ersetzen)

        $ret .= sprintf("%s.%s      %-10s %s\n", $owx_f,$owx_rnf, $chip, $acname);
      }
    }
  }

Vielen Dank! Jetzt geht es vorwärts ... Aber der Reihe nach:

ZitatEnthält, wie angekündigt, das INTERNAL SHELLYID.

Siehe Privatnachricht: Wird beim define noch nicht automatisch gesetzt, wenn das Device noch nicht existierte.

ZitatAußerdem habe ich einen neuen Typ eingeführt, mit dem fiktiven Namen shellyid

Wäre "shellygeneric" nicht systematischer? Aber die Idee ist prima - jetzt weiß ich, "wohin" mit Geräten, deren CoIoT-Device-Typ ich nicht mappen kann. Jetzt lege ich sie so an, und gebe ihnen den Namen "shelly_generic_" . <coiot-device-typ>. "_" <device_id>

ZitatWenn also ein Paket mit dem CoIOT-Protokoll eintrifft, müsste Folgendes passieren:

In der neuen, 3. Version, ist es jetzt so gelöst:
1) Suche die Geräte über die Source-IP des Multicast-Paketes:
my @devNames = devspec2array("TYPE=Shelly:FILTER=DEF=$sending_ip");
2) Gucke, ob in diesen Geräten SHELLYID gesetzt ist. Wenn ja und abweichend, verwirf das Gerät. Wenn nicht gesetzt, setze es (Fallback-Modus für offizielle aktuelle Shelly-Modul-Version)
3) Wenn jetzt die Geräteliste leer ist und "autoCreate=Shelly" gesetzt ist: Suche nach Geräten über die SHELLYID:
my @devsByShellyId = devspec2array("TYPE=Shelly:FILTER=SHELLYID=.*".$shellyId);
Fündig? Dann IP-Adresse aktualisieren über ein "defMod". Habe ich auch getestet, funktioniert, wenn ich einen Shelly von DHCP auf Static stelle.
Nicht fündig? Dann AutoCreate mit dem entsprechenden Model oder shellyid als Fallback.

Ich möchte das noch optimieren, indem ich ein Caching einbaue. Caching ist aber eine gute Möglichkeit, schwer reproduzierbare Fehler einzubauen, daher erst im nächsten Schritt.

ZitatBitte klären: Wird die Geschwätzigkeit via CoIoT abgestellt, wenn man in den Shelly-Oberfläche unter Settings die Option "Make discoverable" abwählt?

Nein, sie lassen sich das Schnattern nicht verbieten. Der Großmeister schreibt dazu auf Facebook:

Dimitar Dimitrov

ZitatIt's add for future app development. If the flag is truem this device will not be present as new device in another app and accounts. This flag is contrled from the cloud, for MQTT customers can be set manually.

https://www.facebook.com/groups/ShellyIoTCommunitySupport/permalink/2684042781695069/
(https://www.facebook.com/groups/ShellyIoTCommunitySupport/permalink/2684042781695069/)

Zusammenfassung
Die 3. Version (im ersten Beitrag verlinkt) kann jetzt AutoCreate von Devices und aktualisiert bei IP-Wechsel eines Shellys die Definition. Voraussetzung: AutoCreate ist an. Das habe ich noch etwas zum Einzeiler beim Define vereinfacht:
define coiot COIOT auto
legt jetzt gleich das Device mit autoCreate an.

Hier die neue Beta2

LG

pah

Moin, ich glaube, dass das Modul jetzt auf die Zielgerade geht. Was die Frage nach dem offiziellen Namen aufwirft.

Ich neige zu 39_Shelly_CoIoT.pm. Alternativen:

39_CoIoT.pm
39_CovIdiOT.pm
39_COIOT.pm

Warum? Weil sonst niemand auf die Idee kommt, dass das Modul der einfachste Weg ist, die Shellys zum Fliegen zu kriegen. Den Namen muss ich wohl festlegen, bevor ich Rudi um den SVN-Zugang bitte.

Nächste Frage: Könnte noch jemand mithelfen, weitere Shellys automatisch zu erkennen? Dafür ist nur nötig, entweder das Modul auf "verbose 5" laufen zu lassen, und hier eine Beispiel-Message aus dem Logfile zu senden, oder aber meinen Sniffer aus diesem Beitrag https://forum.fhem.de/index.php/topic,117243.msg1116311.html (https://forum.fhem.de/index.php/topic,117243.msg1116311.html) 30 Sekunden auf dem Raspi laufen zu lassen. Und natürlich die Info mitzugeben, um welchen Gerätetyp es sich handelt.

Mit der Info können dann mittels dem Modul und dem Shelly_Modul entsprechende Geräte ganz von alleine eingerichtet werden.

Die im ersten Beitrag verlinkte 4. Version des Moduls hat jetzt einen Cache (Sender-IP -> Devicenamen), der bei jedem globalen Event RENAMED|DELETED|DEFINED|MODIFIED zurückgesetzt wird. Damit bin ich auch CPU-mäßig am Ziel.

Ein Tipp noch: Das COIOT-Modul selber ist auch eine Event-Schleuder wegen der State-Updates mit der Statistik. Eine nicht ganz akademische, aber funktionierende Methode, das auf 0 zu ändern, ist:
attr coiot event-on-update-reading nixda
zu setzen. Dann werden die Änderung an "state" nicht mehr in die Welt geblasen - andererseits aktualisiert sich die Ansicht des Gerätes auch nicht.

P.S. Und noch ein 2. Tipp: Wer bei dem Shelly-Modul eine MQTT-Update-Rate nicht gewöhnt ist, kann wohl am besten mit event-aggregator power:30:linear:mean o.ä. die Flut in den Griff bekommen. Gerade hinter Schaltnetzteilen vom Laptop etc. schwankt die Leistung so erheblich, dass die Shellys im Abstand weniger Sekunden Events senden.

Ich kann es morgen mal mit einem Shelly1 und demnächst mit einem Shelly1 L laufen lassen (falls die interessant sind)...

Gruß, Joachim

Ja, super! Ich muss nur wissen:

Sie melden sich so:
URI: /cit/s, global_devid = SHPLG-S#7ADEA2#2, validity=3840, serial=645,

und das Setting für model sollte "xy" sein.

Diese "Device-Prefixe" sind leider nicht von Allterco dokumentiert. Das Beispiel ist ein Shelly PlugS. Ich brauche also nur den "Prefix" und das zugehörige "model"-Attribut für das Shelly-Modul

Ok, kommt!

Sobald ich mich hier mal eingelesen hab und das Modul auf meinem Trstsystem hab...

Shelly1 L dauert noch etwas, der ist noch unterwegs... ;)

Gruß, Joachim

Zum Thema "Name": 1. Nicht zu viele Binnenmajuskeln - CoIoT ist unergonomisch. 2. Nicht zu spezifisch für Allterco. Ich sehe nämlich das Potenzial in diesem Modul, auch andere "Rundfunkgeräte" einzufangen. In dem Sinne wäre ideal: CUL_IP

LG

pah

Scheint funktioniert zu haben, also Device wurde angelegt (aber ich kann [nat.?] nix damit machen)...

EDIT: hier noch das list des angelegten Devices

Internals:
   CFGFN     
   DEF        192.168.1.146
   DURATION   0
   FUUID      5ff2f61e-f33f-19f1-2f45-5180ffb16c184553
   INTERVAL   600
   NAME       shelly_generic_shsw_1_98f4abf2883b
   NR         925
   SHELLYID   98F4ABF2883B
   STATE      initialized
   TCPIP      192.168.1.146
   TYPE       Shelly
   READINGS:
     2021-01-04 12:03:58   cloud           disabled
     2021-01-04 12:14:00   firmware        1047-long-id-for-shelly-devices(update needed to v1.9.3)
     2021-01-04 12:03:58   network         <html>connected to <a href="http://192.168.1.146">192.168.1.146</a></html>
     2021-01-04 12:03:58   relay_0         off
     2021-01-04 12:03:58   state           initialized
Attributes:
   interval   600
   model      shellyid


EDIT: ok, jetzt... Klar model setzen und gut. Ich schau mal, ob ich das im Code finde und was machen kann... Ansonsten kann ich auch warten ;)

Das ist die Zeile aus dem Log die du brauchst?


2021.01.04 12:05:13 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#1, validity=3840, serial=2


Es ist ein Shelly1

Log schicke ich zu und ob ich mich im Code zurecht finde werden wir sehen...
...aber ich glaube da darfst du dich "austoben" ;)

EDIT: ok, irgendwie kann ich per PN kein Log (oder irgendeine Datei) schicken?! Wenn du die Logdatei noch brauchst, dann hänge ich sie hier rein...

Wenn ich noch was testen/liefern kann/soll einfach Bescheid geben, noch kann ich alles machen, ist aktuell nur in meiner Testumgebung aktiv...

Einen kleinen Fehler in einer Logmeldung habe ich enteckt:

Zitat
Perl-Module IO::Socket::Multicast not found. Either execute "sudo apt-get install apt-get install libio-socket-multicast-perl" (for Raspbian Buster), or "sudo cpan install IO::Socket::Multicast"

Müsste (zumindest bzgl. apt-get) so lauten:

Perl-Module IO::Socket::Multicast not found. Either execute "sudo apt-get install libio-socket-multicast-perl" (for Raspbian Buster), or "sudo cpan install IO::Socket::Multicast"


EDIT:
Also ich war etwas "verwirrt" von deiner Code-Zeilenangabe ;)

Zitat
Code in Zeile 472 ff. erweitern, um die Readings im Shelly-Device zu setzen

Bzw. schließe ich nicht aus, dass ich was übersehen habe... ;)
(Perl ist nicht so meine Stärke...)

Und ich habe auch das FETT "übersehen" was denn nun in der Ausgabe im Log wichtig ist ;)

Zitat
Sie melden sich so:
URI: /cit/s, global_devid = SHPLG-S#7ADEA2#2, validity=3840, serial=645,

Ich habe mal die "Map" erweitert und schon wird mein Shelly1 auch als solcher angelegt :)
Ist es das was man ergänzen muss oder habe ich was übersehen?


# Mapping of DeviceId in Multicast to Shelly model attr
my %DEVID_MODEL = (
    "SHPLG-S" => "shellyplug",
    "SHSW-PM" => "shelly1pm",
    "SHSW-25" => "shelly2.5",
    "SHDM-2" => "shellydimmer",
    "SHSW-1" => "shelly1"
);
my %DEVID_PREFIX = (
    "SHPLG-S" => "shelly_plug_s",
    "SHSW-PM" => "shelly_1pm",
    "SHSW-25" => "shelly_2",
    "SHDM-2" => "shelly_dimmer",
    "SHSW-1" => "shelly_1"
);


Gruß, Joachim

OK, Ergänzungen:

SHSW-44 => Shelly 4Pro, also model=shelly4
SHSW-21 => Shelly 2 (nicht 2.5), also model=shelly2

Die SHSW_25 sollten nicht mit dem Namen shelly_2_xxxxx angelegt werden, sondern als  shelly_25_xxxxx

Außerdem rege ich an, von der reinen Zählung der Messages zu einer Zählung pro Stunde überzugehen, sonst wächst die Zahl schnell ins Gigantische.

Note Added in proof: Ich habe derzeit 14 Shelly-Devices im Einsatz. Ich polle diese maximal 1x pro Minute - in vielen Fällen auch gar nicht, weil ich bei lokalen Statusänderungen (Button gedrückt) über den Shelly selbst eine Statusabfrage antriggere. Macht also pro Stunde ca. 500 Events. Wenn ich die COIOT-Daten annehme, bekomme ich in der gleichen Zeit die vierfache Menge an Daten. Da sollten wir mal testen, inwieweit das FHEM ausbremst.

LG

pah

@Joachim, vielen Dank! Irgendwie habe ich keine Mail bei Deinem Beitrag bekommen. Aber egal - in Summe hast Du alles richtig zugeordnet.

Die Gesamttabelle (ab Zeile 200) mit den Ergänzungen & Korrekturen von pah sieht jetzt so aus:

# Mapping of DeviceId in Multicast to Shelly model attr
my %DEVID_MODEL = (
    "SHPLG-S" => "shellyplug",
    "SHSW-PM" => "shelly1pm",
    "SHSW-1" => "shelly1",
    "SHSW-21" => "shelly2",
    "SHSW-25" => "shelly2.5",
    "SHDM-2" =>  "shellydimmer",
    "SHSW-44" => "shelly4"
);
my %DEVID_PREFIX = (
    "SHPLG-S" => "shelly_plug_s",
    "SHSW-PM" => "shelly_1pm",
    "SHSW-1" => "shelly_1",
    "SHSW-21" => "shelly_2",
    "SHSW-25" => "shelly_25",
    "SHDM-2" => "shelly_dimmer",
    "SHSW-44" => "shelly_4"
);


ZitatAußerdem rege ich an, von der reinen Zählung der Messages zu einer Zählung pro Stunde überzugehen, sonst wächst die Zahl schnell ins Gigantische.

Ist mir jetzt nicht so klar. Die Zielsetzung: Der Nutzer legt das COIOT-Device an, und sieht binnen 30 Sekunden: "Da tut sich was! Oh, ja, 8 Shellies insgesamt, kommt hin". Oder anderer Usecase: "Warum hat sich jetzt nichts getan, als ich den Button gedrückt habe? Device aufrufen, feststellen: Oh, da läuft noch was rein!".

Meinst Du einen Counter-Reset immer dann, wenn die Kirchuhr voll schlägt?

ZitatWenn ich die COIOT-Daten annehme, bekomme ich in der gleichen Zeit die vierfache Menge an Daten. Da sollten wir mal testen, inwieweit das FHEM ausbremst.

Bei mir läuft FHEM auf einem Raspi 3B+ mit 10%. Eventsau Nr. 1 ist der OBIS-Lesekopf mit ca. 2-3 Sek. Intervall für einen Datensatz mit 4-6 Events (Phasen, Gesamt, Zählerstand), und sehr viel Folgeverarbeitung (Energiemanagement). Ich habe das "readingBulkUpdateIfChanged" von Mod_Shelly übernommen - bei MQTT wird ohne "IfChanged" geupdated. Daher gehe ich davon aus, dass

• halbwegs moderne Raspis kein Problem haben
• der Anwender immer noch besser in Sachen CPU als mit MQTT weg kommt

Bei mir läuft das Modul mit 12 Shellies ohne merkliche CPU-Änderung, vor allem seit dem IP-Caching von Version 4.

Andere Fragen:

• Ich lege neue Device mit einem Poll-Intervall von 10 Minuten an. Andere Vorschläge?
• Ist es sinnvoll, dass die Geräte auch automatisch ein Room-Attribut bekommen?

Zitat von: gvzdus am 04 Januar 2021, 17:12:13
@Joachim, vielen Dank! Irgendwie habe ich keine Mail bei Deinem Beitrag bekommen. Aber egal - in Summe hast Du alles richtig zugeordnet.

Ok, gut.

Den Shelly 1L liefere ich dann, sobald er da ist...

Da habe ich jetzt aber auch schon mal wegen Präfix eine Frage: shelly1 und dann shelly1l?

@pah: shelly1l gibt es ja (noch) nicht im Shelly-Modul!? So richtig weiß ich auch nicht, was der Unterschied ist bzw. so wie ich es aktuell weiß "nur", dass der 1L auch ohne Nutral-Leiter kann... Ansonsten sind die ja (wohl) gleich... Wie also "integriere" ich das dann hier? Weil am Ende soll ja ein define für das Shelly-Modul "rauspurzeln"...

Zitat von: gvzdus am 04 Januar 2021, 17:12:13
Andere Fragen:

• Ich lege neue Device mit einem Poll-Intervall von 10 Minuten an. Andere Vorschläge?
• Ist es sinnvoll, dass die Geräte auch automatisch ein Room-Attribut bekommen?

Also ich würde das Autocreate gerne manuell anstoßen.
Bzw. ist es eh die Frage: kann/könnte man das "spezifisch" machen, also ein Device auswählen und das dann anlegen lassen? :-)
Alternativ halt manuell, dann kann man ja Devices die angelegt wurden, man aber nicht haben will, wieder löschen...
(z.B. man will auch mal per mqtt einbinden oder selber was mit HTTP machen oder oder)

Wenn die dann immer wieder kommen/kämen, wäre das u.U. "doof"...


Ein Attribut room wäre gut, dann würde man die leichter finden.
Und: viele andere Module (bzw. autocreate "für" diese) machen das auch...

Gruß, Joachim

Zitat von: gvzdus am 04 Januar 2021, 17:12:13
Ist es sinnvoll, dass die Geräte auch automatisch ein Room-Attribut bekommen?

machen viele Modul Autoren, so sind die Schäfchen in einem Stall und der unerfahrene User sucht sich keinen Wolf unter Everthing.

Zitatmachen viele Modul Autoren, so sind die Schäfchen in einem Stall und der unerfahrene User sucht sich keinen Wolf unter Everthing.

Wenn man das mit autocreate machen will, setzt man in Modul_Initiialize des Zielmoduls Folgendes:
$hash->{AutoCreate} = { "devNameRegexp"=> { ATTR=> "room:myRoom group:myGroup" } };

Zunächst einmal @Joachim: Der Shelly 1L wird vermutlich am besten als Model "shelly1pm" eingetragen. Denn auch hier haben sie wieder Power-Metering, und pah hat den Shelly1 als Gerät ohne Powermetering definiert, den Shelly1PM als Gerät mit PM.

Vielleicht meldet er sich ja auch im Broadcast wie ein Shelly1PM, wir (Du) werden sehen...

@Rudi: Ich muss mich in das "AutoCreate" wie Du es meinst mal einlesen. Im Moment schieße ich einfach "CommandDefine"-Aufrufe los, habe ich mir von MQTT abgeguckt.

@Joachim: "Legt Geräte mit Poll-Intervall 600 an" meinte: "Während ohne Angabe das HTTP-Polling-Intervall der Shelly-Devices auf 60 Sekunden gestellt wird, legt COIOT die Devices mit 600 Sekunden HTTP-Polling-Intervall an". Angelegt werden die Geräte sofort, sofern "autoCreate" auf "Shelly" steht, sobald ein CoIoT-Paket reinkommt.
Dein Vorschlag gefällt mir, aber ich muss mal gucken, ob ich da eine simple Methode finde.

Ich habe jetzt gelesen, bin aber erst so mittelklug...

Joachims Wunsch "Nicht brutal alles anlegen, sondern Anzeigen und auf Klick anlegen" finde ich sinnvoll. Von der "Userstory" stelle ich mir das so vor: Man tippt das "define coiot COIOT", sieht zunächst den relativ leeren Screen des Devices, dann, mit jedem eintreffenden CoIoT-Paket nicht nur einen ansteigenden Counter, sondern eine sich aufbauende Tabelle:

Defined devices:

IP	Model	Name
192.168.0.10	shelly2.5 / roller	Kuechenrollladen

Undefined devices:

IP	Model	Create?
192.168.0.11	shelly2.5 / roller	Click to create
192.168.0.12	shelly2.5 / roller	Click to create

Das könnte man sich über ein devStateIcon basteln. Aber dann ist auch die ganze fette Tabelle in Everything & Co zu sehen. Ist die Umsetzung über devStateIcon FHEM-Mißbrauch oder von der Kunstfreiheit abgedeckt? Falls Mißbrauch: Was sollte ich lesen?

AutoCreate
Was ich so auf die Schnelle finde: Du, Rudi, hast Dir das 2-stufige Modulkonzept ausgedacht. So ganz unpassend ist es nicht. ABER: Mod_Shelly kommt von pah, Mod_Coiot von mir. Ich weiß nicht so recht, ob Dein autoCreate darauf passt. "Mein" autoCreate ist halt das direkte Abfeuern von CommandDefine und CommandAttr-Sequenzen. Ist das auch von der Kunstfreiheit abgedeckt, ober FHEM-Mißbrauch?

Das Modul HUEBridge hat auch ein eigenes? Autocreate für "Lampen"...

set HueBridge autocreate autocreateDevices (oder so ähnlich / müsste nachsehen)...
EDIT: Ob HueBridge "autocreate" nutzt oder "alles" selber macht weiß ich nicht...

Dabei werden auch alle noch nicht definierten Devices angelegt.
Wenn man welche nicht will, kann man die ja löschen.
Die werden dann zwar beim nächsten set autocreate wieder angelegt und "müssen" wieder gelöscht werden aber das wäre (für mich) auch i.O.

Liste mit Auswahl wär nat. superklasse :)

Gruß, Joachim

Dann warten wir mal auf das Urteil des Königs in Sachen Mißbrauch vs. Kunst.

Dann gibt es noch die wechselnde IP. Im Moment verhält sich das Modul ja so: Ist "autoCreate" ein, und stellt COIOT einen Wechsel der IP-Adresse anhand des von pah eingebauten Internals SHELLY-ID fest, dann wird das entsprechende Shelly-Device auf die neue IP um"defined" / ("defmod"ded). Bei autoCreate off zuckt COIOT mit den Schultern und verwirft das Paket.

Vorschlag:
Dieses Verhalten wird ein eigenes Attribut des COIOT-Moduls mit dem Namen "updateIpById 0:1". Default 1. Weil m.E. mehr Nutzen als Schaden.

Kunstfreiheit: ich will keinem was verbieten, aber wir sollten, wenn moeglich, den Benutzer nicht immer wieder zwingen, was Neues zu lernen.

Autocreate ueberwacht "global:UNDEFINED deviceName deviceType define-Arguments", und ruft selber CommandDefine auf, legt ein FileLog an, und falls bekannt ein SVG, und setzt das room Attribut auf TYPE. All das kann der Benutzer aendern oder ausschalten.
Ich schlage vor, zunaechst das UNDEFINED Event zu generieren, und dann schauen, ob was fehlt.

Wg. Darstellung: ich wuerde auch erstmal mit dem set autocreate versuchen, das waere dann genauso wie beim HUE.
Optional mit weiterem Argument (Devicename oder *). Die Liste kann man kommagetrennt an set kleben, dann muss der Benutzer nichts tippen.
Wenn Du Tabelle bauen willst, dann am besten gleich wiederverwendbar :)

Zum Thema autocreate: Hier sollte, ebenso wie bei der Weitergabe von Events, eine Ausschlussliste an Hand von speziellen Devicenamen UND an Hand des model-Attributes abgearbeitet werden. Ich möchte beispielsweise nicht, dass die ganzen einlaufenden Daten von meinen Shelly 2.5 Rollladenaktoren an diese in FHEM weitergereicht werden. Also z.B. als Attribute

ZitatexcludeDevices <Liste>
excludeModels <Liste>

Zum Thema Tabelle: Solche anklickbaren Tabellen in der Detailansicht werden generiert von meinen Modulen 95_Alarm.pm, 95_Babble.pm, 95_PostMe.pm, 95_YAAHM.pm, 70_DoorPi.pm. Und nicht von mir: FritzBoxCallList.

Das ist zwar alles ziemlich speziell, und ob man daraus mit vertretbarem Aufwand etwas Wiederverwendbares machen kann, wage ich zu bezweifeln. Aber vielleicht kann man einfach etwas übernehmen.

LG

pah

So, dann kam doch glatt heute noch der Shelly1L:


2021.01.05 18:10:29 5: URI: /cit/s, global_devid = SHSW-L#84CCA8ACBE60#2, validity=3840, serial=4


Ich habe mal beides ausprobiert, also shellypm und shelly1: geht beides.

Ja es gibt eine Leistungsmessung bzw. anders: es gibt Leistungswerte ABER: man kann auf der Webseite des Shelly angeben wieviel Leistung denn gezogen wird, wenn eingeschaltet ist und das wird dann angezeigt usw.

Also darauf kann ich verzichten...
...aber vielleicht wird das ja in zukünftigen FWs noch...

Wenn ich nich was tun/liefern kann: einfach Bescheid geben...
...allerdings werden die wohl demnächst auf das Hauptsystem ziehen und dort dann (erst mal) ohne CoIoT laufen...

Gruß, Joachim

Erst mal Danke, Joachim!

Eigentlich hatte ich gestern einen Plan für heute, bin aber vom Ziel weiter weg als mit der gestrigen Version.
Einerseits habe ich lange mit der Perl-Hölle der Referenzen auf Hashes in Array, die Referenzen sind, u.s.w. gekämpft, um auch nur das Modul ohne Crash laufen zu lassen.

Zum anderen hatte ich eigentlich einen Plan, was jetzt aus den 3 Inputs werden sollte:
Eine Tabelle in der Device-Ansicht, die alle aktiven IPs anzeigt, die zugehörigen definierten Module und die Geräte, die auf einen Klick zur Definition warten. Damit wollte ich eigentlich das "Paket-Zählen" ablösen, denn diese Tabelle braucht keine Updates (solange nichts passiert), und gibt trotzdem Feedback: "Hey, das ist bei Dir so da"

Allerdings gelingt es mir nicht, die "Kunstfreiheit" so weit zu treiben, dass aus dem State tatsächlich eine mehrzeilige Tabelle wird. Auch das PostIt-Beispiel funktioniert mit meiner ziemlich aktuellen FHEM-Version nicht wirklich - es gibt eine große leere Fläche in der ersten Zeile.

Ich muss mal gucken, wie ich morgen weiter mache, und ob irgendwas vom heutigen Code wiederverwendbar ist.

Hallo,

jetzt "muss" ich mich dann (doch) noch mal melden.

Ich habe heute einen Shelly in "sein" eigentliches Netz umgezogen: IoT-Netz eigenes V-LAN.

Dann ist nat. (erst mal) "essig" mit dem CoIoT.
EDIT: nat. den Shelly gelöscht und auch das CoIoT und dann CoIoT neu angelegt...

Ja ich weiß ich müsste nur mehr erlauben zwischen den Netzen, so wie bei den Google-Cast/Chrome-Cast Dingern (will ich aber eigentlich nicht).

Steuerbar ist er nat. mit dem Shelly-Modul (habe ihn manuell angelegt).

Wollte ich hier nur loswerden.
Obwohl verm. "bekannt" bzw. "erwartet"...

Wie wäre denn das Verhalten bei einem IP-Wechsel.
Also ich nehme ihn ins Netz -> DHCP vergibt Adresse -> CoIoT-Device findet ihn (und legt ihn an)
Dann vergebe ich (im DHCP) die eigentliche Adresse -> "reboot" dann mit neuer Adresse und dann?
(ja ich könnte vorher die MAC irgendwo rausfummeln [steht ja evtl. außen drauf?] und dann vorher schon eintragen / ich mache es aber [meist] andersrum)

Ja, könnte ich auch schnell testen, hab aber (leider) grad andere Dinge zu tun.

Gruß, Joachim

(Edit) Es ist viel sinnvoller, die Adressen der Shellys _eben nicht_ variabel per DHCP zu setzen, sondern fest zu vergeben (per DHCP-Einstellung und/oder direkt im Device). Ich werde auch nicht davon abweichen, das über eine IP-Adresse statt über einen Hostnamen zu machen. Die normalen DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

LG

pah

ZitatDie DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

Es sei denn, der Modulautor verwendet HttpUtils_gethostbyname() UND der Benutzer hat "global dnsServer" gesetzt :)

Zitat von: Prof. Dr. Peter Henning am 06 Januar 2021, 19:50:28
Es ist viel sinnvoller, die Adressen der Shellys _eben nicht_ per DHCP zu setzen, sondern fest zu vergeben. Ich werde auch nicht davon abweichen, das über eine IP-Adresse statt über einen Hostnamen zu machen. Die DNS-Anfragen sind nämlich _nicht_ Non-Blocking und können FHEM komplett ausbremsen.

LG

pah

Nicht gleich wieder lospoltern!

NIEMAND hat hier etwas von "HOSTNAME" geschrieben!

Und sehr wohl vergebe ICH meine (durchaus) festen IP-Adressen per DHCP!
(es gibt sowas wie: bitte lieber DHCP-Server, wenn diese MAC frägt, dann gib doch dem Client immer diese IP ;)  )

Und das ist ein ganz normales Szenario und hat nichts mit dem Shelly-Modul zu tun!

Denn selbst wenn ich die IP fix im Shelly einstelle: er muss ja auch dazu erst mal ins Netz...

Ich wollte lediglich HIER (CoIoT!) loswerden, dass es eben (ohne weitere "Massnahmen") nicht zwischen V-LANs geht und einfach nur fragen was denn die "Strategie" ist (seitens CoIoT!!) wenn sich die IP ändert.

Nur als Frage.
Mir aber nicht so wichtig, weil ich kann es ja auch einfach ausprobieren was passiert...

Und entweder hier teilen was passiert ist (falls es interessiert) oder für mich behalten (wenn es niemanden interessiert)... ;)

Gruß, Joachim

Nach dem gestrigen Frust habe ich heute nicht weiter gemacht. Aber Deine Frage will ich heute noch beantworten: Version 4 geht so vor: Bei "autocreate" wird vor dem Anlegen eines neuen Device geprüft, ob die (unveränderliche) Shelly-ID bei einem anderen Device existiert, und wenn ja, das Device auf die neue IP aktualisiert. Etwas übergriffig, aber fully DHCP-compatibel.

Zitat von: gvzdus am 06 Januar 2021, 23:31:19
Nach dem gestrigen Frust habe ich heute nicht weiter gemacht.

Ohje...

Na dann mach doch mal ne Pause! ;)

Zitat von: gvzdus am 06 Januar 2021, 23:31:19
Aber Deine Frage will ich heute noch beantworten: Version 4 geht so vor: Bei "autocreate" wird vor dem Anlegen eines neuen Device geprüft, ob die (unveränderliche) Shelly-ID bei einem anderen Device existiert, und wenn ja, das Device auf die neue IP aktualisiert. Etwas übergriffig, aber fully DHCP-compatibel.

Danke.
Wieso "übergriffig"...
Genau das hatte ich mir gedacht bzw. "erwartet"... :)

Gruß, Joachim

@MadMax-FHEM: Hmmmm - Ich habe doch nicht "losgepoltert" ? Du hast natürlich Recht mit der Einstellung des DHCP-Client, so mache ich es ja auch. Ich habe das oben präzisiert.

LG

pah

"Übergriffig", weil eine vom Benutzer festgelegte Konfiguration "besserwissend" überbügelt wird. Deswegen auch die Verknüpfung mit autocreate: Nach dem Motto, wenn "ich COIOT" eh' dafür zuständig bin, die Devices anzulegen, dann darf ich sie auch umkonfigurieren.

Mit etwas Abstand bin ich jetzt dazu gekommen, dass meine gesuchte Funktion, eine (ggf. größere) HTML-Tabelle im FHEMWEB-CoIoT-DeviceView zu rendern, geht:
Irgendwann fiel mir ein: "Hey, wie macht das eigentlich das SVG-Device?". Und jetzt habe ich FW_detailFn entdeckt.
Damit geht es ja wohl.

Der Kampf gegen die Referenzen auf Hashes mit referenzierten Arrays auf referenzierte Objekte kann also weitergehen. God bless America, und hoffentlich keine Meldungen über unblessed references im Logfile mehr...

Wenn ich helfen kann, sag Bescheid.

LG

pah

Vielen Dank, der Kampf war zwar zäh, aber Du wärest vermutlich nicht darauf gekommen, mir den Tipp zu geben, dass mein Fehler in Sachen HTML die unschuldige Redefinition einer Variable mit "my" wäre... Jetzt klappt es auch mit HTML.

Stand der Dinge ist jetzt wieder dem Release entgegengehend.

TODO:

• ignoreDevice checken
• expiry von Devices, die sich nicht mehr melden
• LogLevel von Meldungen anpassen
• ??

Ich hänge das Modul diesmal hier direkt an, weil es im Vergleich zu V4 eher wackeliger als stabiler ist - dafür mal ein Screenshot, wie ich mir das so vorgestellt und umgesetzt habe. Die "fett grünen" Devices sind definiert, die kursiven werden beim "Create" angelegt.
Noch schöner wäre ein Popup mit einem Textfeld, was gleich fragt: "Willst Du nicht einen schöneren Namen als shelly_plug_s_7adea2 wählen?". Aber ob das im "Werkzeugkasten" für eine GUI so vorgesehen ist, ist mir unklar.

Vorgesehen ist uebertrieben, aber im attrTemplate realisiert.

Naja, ein rename kann man vom Anweder schon noch "verlangen" ;)

Da sind andere Module auch nicht "besser" und die meisten die ich so kenne nehmen auch "irgendeine" Device-ID zum "generieren" eines Namens...

Leider habe ich grad nur noch einen Shelly zum Testen ;)

Die anderen sind verbaut und im "eigenen Netz", da klappt das ja mit dem "Finden" nicht so...

Aber mal sehen, vielleicht bestelle ich noch ein paar (ca. 2 könnte ich noch "brauchen" / dann ist aber gut mit Wifi-Dingern)...

Gruß, Joachim

Moin Joachim,

Ich will Dich nicht nötigen, im Produktionsnetz zu spielen. Bin glücklich, jetzt mein Testsystem auf einem weiteren Raspi hochgezogen zu haben, damit die Frau nicht immer gleich mit xy droht, wenn im Flur nicht das Licht angeht.

ABER:
Das Modul wertet Multicast aus. Multicast ist kein Broadcast, Multicast ist durchaus dafür vorgesehen, über einen Router hinweg weitergeleitet zu werden. Multicast ist normalerweise am DSL/Kabel-Modem gefiltert, weil Deine Shellys ihren Stand ja nicht weltweit teilen sollen. Ebenso auf Providerebene. Aber zwischen zwei Netzen daheim sollte es ein Setting am Router sein.

Viele Grüße, Georg

Ich weiß schon, dass das "nur" ein Setting im Gateway ist... ;)

Aber was nicht hin und her muss, muss nicht hin und her ;)

Evtl. kann ich ja zum Testen mal meinen Test-PI ins andere Netz umziehen...

Aber egal wie brauche ich erst mal wieder Zeit dafür...
...am WE ist Familie und ab Mo leider wieder Arbeit...

Da muss ich erst sehen, was da los ist ;)

Gruß, Joachim

Ich bin jetzt eigentlich wieder da, wo ich mit Version 4 war: Scheint zu laufen.

In der Tabellenansicht kann man per Klick Devices anlegen, alternativ mit dem Befehl "set <coiot> autocreate <ip-pattern>".
Die Devices erhalten jetzt ggf. auch ein passendes webCmd-Attribut.

Die Erkenntnisse von Tim zum Shelly Duo sind eingearbeitet.

Das "AutoCreate" ist aber immer noch ohne Nutzung des Auto-Creates. Ich habe ca. 1 h recherchiert, und war eher verwirrt durch das Gefundene. FHEM ist halt kein Manual, was man durchliest, sondern Foren + Wiki + Rätseln. Einerseits ist die Beziehung COIOT zu Shelly-Modul ja das zweistufige Konzept, andererseits kommt das Shelly-Modul sehr gut auch ohne "mich" zurecht und benötigt kein Dispatching der Daten der physikalischen Schnittstelle.

Lieber Rudi, das mit dem "AutoCreate nach reiner Lehre" würde ich gerne noch umsetzen, weil die Vorteile so sind, wie ich FHEM kenne: Eine File-Log wird angelegt, u.s.w. Mir ist aber unklar, ob das "Kooperation" durch das Shelly-Modul voraussetzt, und wie ich das richtig auslöse ("Dispatch" ?). Darf ich da um die Aussage "Klappt auch mit Shelly-Modul as is" und "Guck mal Zeile xy im Modul z" bitten? Das ist ein vermutlich Zeit-Tausch-Verhältnis von weit über 1:10... :-)

Erst pruefen, ob die Instanz, was man anlegen will, noch nicht existiert. Ueblicherweise passiert das im ParseFn eines Moduls, was von Dispatch aufgerufen wurde, anhand Modul lokalen Daten ($modules{XX}{defptr} oder my %var).
Dann einen String basteln, was einem define entspricht, bloss statt define das Wort UNDEFFINED verwenden: "UNDEFINED FS20_$dev$btn FS20 $dev $btn"
Mit diesem String ein global Event generieren: DoTrigger("global", "UNDEFINED..."). Im ParseFn-Fall reicht diesen String zurueckzuliefern, DoTrigger uebernimmt Dispatch selbst.

autocreate hoert auf global:UNDEFINED.*, und wandelt es in CommandDefine um, setzt room, legt FileLog an, etc, all das kann der Benutzer aendern/unterbinden, bzw. das Zielmodul(!) ueber $modules{XX}{AutoCreate} beeinflussen.

Falls man weiteren Schabernack mit dem gerade angelegten Instanz treiben will, dann kann man z.Bsp per PrioQueue_add() oder InternalTimer(0,...) direkt vor DoTrigger (bzw. dem return in ParseFn) eine Funktion einhaengen, und hier die nachtraeglichen Aktionen ausfuehren. Beispiel dafuer siehe 10_MQTT2_DEVICE.pm

Vielen Dank, Schritt 1 klappt wunderbar.

Zum Schabernack, in meinem Fall mit "Attr": Im Code sieht das jetzt so aus und funktioniert:

   
DoTrigger("global", "UNDEFINED $dname Shelly $ip");
CommandAttr ( undef, $dname . ' model ' . $model);
CommandAttr ( undef, $dname . ' interval 600' );


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

Und, weil jetzt eigentlich nur noch das "Expiren" von Devices fehlt, die sich nicht mehr melden:

Zum Modulnamen:
pah hatte COIOT für gut befunden, oder "CUL_IP", wenn man höher zielt. Meine Alternativen finde ich selber nicht mehr gut.
COAP ist m.W. irreführend, weil ein Modul, dass nur eine ganz konkrete Herstellervariante spricht, nicht den Namen für sich reklamieren sollte.

Ich möchte noch den Namen "AutoShelly" in die Runde werfen. Oder "ShellyManager"? "ShellyCreate?"

Warum? Weil CoIoT eine Allterco-spezifische Bezeichnung ist, die bei quasi niemandem "etwas triggert". Ziel ist aber, dass ein Nutzer aus dem Namen halbwegs ableiten kann, dass es etwas mit der Hardware vor der Nase zu tun hat.

Meinungen?

Also ich bekomme demnächst noch 2 (oder 3) Shellys und einen "Test-Shelly" hab ich noch, werde also mal wieder "rumspielen" können...

Wie wäre Shelly-Monitor?

Shelly-Create klingt "eigenartig" und Shelly-Manager etwas "groß", wobei ich ja nicht weiß, was du mit dem Modul noch bor hast... ;)

Gruß, Joachim

39_ShellyMonitor ist okay, gefällt mir besser als 39_COIOT.

Und wie wäre es mit 36_ShellyMonitor?

Dann wären sie im Listing direkt hintereinander.

LG

pah

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

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.

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:


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

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

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:

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

in meinem Modul, so gibt es beim Laden an die Backe:
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:


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:

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

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


wie auch
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?"

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:


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

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

LG

pah

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.

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)

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

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.

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

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:

   
    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.

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

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?

Naja, ob "man" den "Spezialfall" ;) von mir "abfangen muss": keine Ahung...

Aber es wäre im Forum vermutlich eine der ersten Fragen gewesen: ist autocreate aktiv... ;)

Ich habe halt auf meinem Testsystem schon lange nicht mehr mit Modulen gearbeitet, die autocreate nutzen...

Zuletzt eben ein wenig mit HUEBridge-Modul und echodevice-Modul.

Beide haben ein "eigenes" autocreate... ;)

Daher war mir das irgendwie "entfallen", dass ich autocreate "brauche"...


Ohje. ob 1. (fhem autocreate) oder 2. ("eigenes autocreate") (wenn ich das richtig "erfasst" habe) ist wohl eine "Glaubensfrage"... ;)

Den Namen gleich beim Anlegen angeben/ändern zu können ist schon "schick" aber eigentlich ist das "rename" schon "usus"... ;)

Und beim HUEDevice geht NAME ändern gar nicht, sondern nur alias ebenso echodevice...

Wird wohl nicht helfen meine Antwort, leider...

Gruß, Joachim

Hier eine Version, die das Input-Feld hat.
Klick löst jetzt das "harte" Define-Kommando aus, und zwar über das Kommando "create" statt "autocreate". Siehe Doku.
"autocreate" hingegen nutzt das AutoCreate-Modul.

Screenshot anbei.

Ganz gefällt mir das nicht. M.E. sollte entweder "autocreate" vollautomatisch sein - ohne Klick oder Kommando - so ist es bei anderen Modulen. Meinetwegen per Default off. Allerdings würde ich als Anwender lieber in der Tabelle gleich einen hübschen Namen eingeben. Doku ist m.E. gefixt, außerdem Fehlermeldungen eingebaut.

Zitat von: gvzdus am 13 Januar 2021, 13:24:21
Hier eine Version, die das Input-Feld hat.
Klick löst jetzt das "harte" Define-Kommando aus, und zwar über das Kommando "create" statt "autocreate". Siehe Doku.
"autocreate" hingegen nutzt das AutoCreate-Modul.

Probiere ich gerne heute Abend mal aus...
...d.h. autocreate kann "aus" bleiben!? :)
Bis dahin ist verm. auch schon mein RGBW2 da :)

Zitat von: gvzdus am 13 Januar 2021, 13:24:21
Ganz gefällt mir das nicht. M.E. sollte entweder "autocreate" vollautomatisch sein - ohne Klick oder Kommando - so ist es bei anderen Modulen. Meinetwegen per Default off. Allerdings würde ich als Anwender lieber in der Tabelle gleich einen hübschen Namen eingeben. Doku ist m.E. gefixt, außerdem Fehlermeldungen eingebaut.

Naja andere Module die autocreate "automatisch" nutzen (zumindest die mit denen ich so "umgehe") haben aber meist einen "Anlernvorgang" vorne weg.
Also Homematic (CUL_HM), ZWave, EnOcean: "Controller" in "Anlernmodus", dann Gerät in "Anlernmodus" und dann "kommt" ein Gerät per autocreate...
Also nur der Schritt: "Anwender wollte ja wohl was Neues, also bekommt er auch was Neues" ist automatisch aber davor "muss" der Anwender ja eh schon genug Knöpfe drücken...

Hier ist es ja so: Anwender schließt Shelly an Strom, nimmt ihn ins WLAN auf und dann tauscht er schon "plötzlich" in fhem auf... ;)

UND (gut vielleicht wieder exotisch): ich habe 2 fhem (gut eigentlich 3: 1x Hauptsystem und 2x Testsystem). Hätte ich in jedem fhem das Modul laufen, hätte ich "plötzlich" jeden Shelly 3x ;)

Also so ein "Auswählen" und "Klicken" (müssen) fände ich schon ok :)

Gruß, Joachim

Zitat...d.h. autocreate kann "aus" bleiben!?

Ja, für den Klick. Du kannst auch mal "set ShellyMonitor autocreate 192.168.0.*" bei ausgeschaltetem autocreate eingeben, dann *sollte* eine Fehlermeldung kommen.

Zitat... Also so ein "Auswählen" und "Klicken" (müssen) fände ich schon ok :)

Ich neige inzwischen zu:

• Klick ist hübsch, sollte aber auch auf autocreate gehen, und eben meckern, wenn's nicht klappt.
• autocreate wirkt wie autocreate bei MQTT etc., ist aber per Default aus. Wenn's an ist, wird alles sofort automatisch angelegt - wie es vorher bei 39_COIOT war

Daneben noch eine Frage:

• Ich neige nicht zum Webdesign: Mein HTML-Table (ohne viel CSS) ist nur mittelhübsch. Wenn's da sinnvolle CSS-Attribute gäbe, übernehme ich sie gerne - treibe das aber nicht

Eine Änderung habe ich noch vorgenommen: Der Code für das Reload der ShellyMonitor-Seite war der hier:
    FW_directNotify("#FHEMWEB:WEB", "location.reload('true')", "") if ($ip2devicesDirty>0);


Nachteil: Der Bildschirm "zuckt" bei den ersten 30 Sekunden nach Neustart bei jedem neu erkannten Shelly - auch auf anderen FHEM-Seiten als dem Shelly-Monitor. Ist jetzt durch:

   FW_directNotify("FILTER=$name", "#FHEMWEB:WEB", "location.reload('true')", "") if ($ip2devicesDirty>0);


ersetzt (Thread von Rudi aus 08/2019 gefunden). Hab' die Version in meinem Posting oben (#62) ersetzt.

Zum Testen brauche ich noch etwas...

Werde mal meine Shelly alle löschen und dann mal "spielen".

Spielwiese: Shelly1, Shelly1L und RGBW2...

Hier auch die Info für den RGBW2:


2021.01.13 18:21:29 5: URI: /cit/s, global_devid = SHRGBW2#80E656#2, validity=3840, serial=4


Gruß, Joachim

Dann warte bitte auf meine nächste Version!

Zitat von: gvzdus am 13 Januar 2021, 18:26:45
Dann warte bitte auf meine nächste Version!

Wollte ich schon anmerken, dss ich das tue, weil dann der RGBW2 auch integriert ist...
...wollte aber nat. nicht "fordern"... ;)

Wie geschrieben: hab erst mal anderes zu tun...

Aber: I'll be back  8)

Gruß, Joachim

Bitte schön, der neuste Scheiß!
Dein SHRGBW2 ist drin, außerdem wird bei Shelly Duos & Shelly Bulbs der (unterschiedliche) Range der Farbtemperatur gesetzt.

Ich hätte ja gerne geschrieben: dann mal her mit dem ganzen neuen Scheiß!

Aber komme frühestens morgen dazu... :-\

Aber schon mal danke!

EDIT: also installiert hab ich schon mal... Problem mit meinem HM_UART hab ich auch hinbekommen :) Willst du bestimmte Sachen "getestet" haben? Wie geschrieben werde ich meine Shelly 1L mal ganz neu anlegen (frisch aus der Packung) und meinen RGBW2 löschen und dann noch mal "suchen" und "anlegen" lassen... Meinen Shelly1 kann ich leider nicht mehr zum Testen nehmen...

Gruß, Joachim

Hi Joachim (oder auch andere Downloader),

ich bin einfach neugierig zu Dingen, die man fixen könnte oder einfacher machen könnte...

Viele Grüße, Georg

Zitat von: gvzdus am 14 Januar 2021, 17:16:51
ich bin einfach neugierig zu Dingen, die man fixen könnte

Lass mal perlcritic auf dein Modul los , dann hast du einiges zu fixen :)

Ein Spruch von mir, den andere für zitierwürdig gehalten haben, ist: "Hinter einen guten GUI sieht niemand den abgrundtief hässlichen Code"

Zitat von: gvzdus am 14 Januar 2021, 17:16:51
Hi Joachim (oder auch andere Downloader),

ich bin einfach neugierig zu Dingen, die man fixen könnte oder einfacher machen könnte...

Viele Grüße, Georg

Ok ;)

Aber leider wurde heute doch nix draus... :-\

Morgen ist auch wieder ein Tag! :)

Gruß, Joachim

OK, hier die fertige 36_Shelly.pm Version 3.0.

Werde ich morgen einchecken.

Noch eine wichtige Änderung: "shellygeneric" halte ich für umständlich lang, daraus habe ich einfach "generic" gemacht.

Den Patch für die Shelly Bulb habe ich übernommen - aber nicht den Teil mit der minimalen und maximalen Farbtemperatur. Das kann man jederzeit per widgetOverride als _ein_ Attribut einstellen, dafür benötigt man keine _zwei_ neuen Attribute.

Ich will auch kein automatisches Setzen des mode - höchstens einen Hinweis im Log. Das ist nämlich potenziell gefährlich für Rollladenmotoren.

LG

pah

"Muss" ich beides verwenden?

Also die neueste 36_ShellyMonitor.pm UND die 36_Shelly.pm?

Oder hat das nichts (direkt) miteinader zu tun?

Testen kann ich doch leider erst morgen :-\

Gruß, Joachim

Moin,

@Joachim: Ich stimme mich noch mit pah ab, um auch den ShellyBulb und ShellyDuo zum Laufen zu kriegen.
@pah: Man kann noch nicht den shellybulb als Modell im Modul auswählen!

Vorschlag Joachim: Warte mal eine gemeinsame Version Shelly + ShellyMonitor ab :-) Wir versuchen, was Abgestimmtes einzubringen, wobei ShellyMonitor dabei von Shelly abhängt. Z.B. das neue "generic" übernehme ich wiederum im ShellyMonitor.

OK, hier die bereinigte Version.

LG

pah

D.h. jetzt warte ich noch auf die ShellyMonitor!?

Ich bastel einfach einstweilen an anderen "Baustellen" rum... :)

Gruß, Joachim

ZitatD.h. jetzt warte ich noch auf die ShellyMonitor!?

Nix warten, hier ist:

Zitat von: gvzdus am 16 Januar 2021, 10:58:00
Nix warten, hier ist:

Mist! ;)

Gruß, Joachim

OK - schieben wir sie ins Repository?

LG

pah

Meinerseits gerne heute Abend! Deine kann m.E. auf jeden Fall rein!

Ich habe jetzt auch commited. Ja, noch mal alles gelesen (überlesen?). Ist allerdings mein erster SVN-Commit zu FHEM - vielleicht Mecker besser gleich per PMail...

Thread zum Modul ist jetzt auch angelegt:
https://forum.fhem.de/index.php/topic,117805.0.html (https://forum.fhem.de/index.php/topic,117805.0.html)

Joachim, Du hast nur noch wenige Stunden, den größten Schaden zu verhindern, bevor das Modul morgen in die Updates geht!

Zitat von: gvzdus am 16 Januar 2021, 14:21:17
Thread zum Modul ist jetzt auch angelegt:
https://forum.fhem.de/index.php/topic,117805.0.html (https://forum.fhem.de/index.php/topic,117805.0.html)

Joachim, Du hast nur noch wenige Stunden, den größten Schaden zu verhindern, bevor das Modul morgen in die Updates geht!

Du setzt mich ja ganz schön unter Druck...

Also das Shelly muss ich manuell vom Repo holen und das ShellyMonitor von "hier" oder auch schon oben (liest sich so)...

Und theoretisch doch Zeit bis morgen früh!? ;)

Gruß, Joachim

Beide Module sollten hier im Thread identisch mit dem sein, was jetzt im SVN ist.
Bis auf die Tatsache, dass ich meine geschwätzige Summary auf 80 Zeichen kürzen musste.

Ok... :)

Bissi brauch ich aber noch... ;)

Gruß, Joachim

ZitatBissi

- ist das ein Hundefutter?

Zitat von: Prof. Dr. Peter Henning am 16 Januar 2021, 15:06:36
- ist das ein Hundefutter?

Ohne (direkt) Österreicher zu sein: https://www.ostarrichi.org/wort/2675/bissi ;)

Gruß, Joachim

So hab ein wenig "rumgetestet!...
autocreate aktiv (war jetzt nicht mehr sicher, dachte: besser mal "einschalten" ;)  ).


Hier mal mein "Mitschrieb" und ein paar Bildanhänge:

Ich hatte ja noch von früheren Tests Devices in der Liste.
Da war die Frage: Löschen von Listeneinträgen?
Ich hab dann einfach mal den ShellyMonitor gelöscht und neu angelegt...
Wollte ja eh "sauber" anfangen...

EDIT: wäre auch gegangen, indem ich die vorhandenen Devices gelöscht hätte (wobei: eigentliich hatte ich das / evtl. noch mit der "alten" Version des ShellyMonitors!?)...
(hat ja "später" funktioniert)

Dann den ersten Shelly (Shelly1) in Betrieb genommen.

Dann (nat.) die IP im DHCP angepasst und neu gestartet (also den Shelly).
Nach dem Ändern der IP-Adresse:
1x Device mit alter IP
1x Device mit neuer IP

in der Liste (siehe Screenshot)...

Create beim Device mit alter IP -> Device wird angelegt (aber geht nat. in Fehler).
In der Liste sind beide Devices mit demselben Link "versehen" (klar) und nat. keine Möglichkeit mehr einen Namen zu vergeben...

Log:

2021.01.16 16:52:08 1: AutoCreate called for IP 192.168.1.146, ip2devices=1
2021.01.16 16:52:08 4: Modified ip2device-cache on event: DEFINED shelly_1_98f4abf2883b
2021.01.16 16:52:09 5: Received data from 192.168.1.160
2021.01.16 16:52:09 5: 192.168.1.160: in cache, devices=shelly_1_98f4abf2883b (size=1)
2021.01.16 16:52:09 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#2, validity=3840, serial=3
2021.01.16 16:52:09 1: Assigning device HASH(0x5b5bf80) SHELLYID 98F4ABF2883B
2021.01.16 16:52:09 5: Found device shelly_1_98f4abf2883b, model shelly1
2021.01.16 16:52:09 5: cfgChanged = 2
2021.01.16 16:52:09 5: output_0 = 0
2021.01.16 16:52:09 5: input_0 = 0
2021.01.16 16:52:09 5: inputEvent_0 =
2021.01.16 16:52:09 5: inputEventCnt_0 = 0
2021.01.16 16:52:12 1: [Shelly_status]  has error connect to http://192.168.1.146:80 timed out
2021.01.16 16:52:24 5: Received data from 192.168.1.160
2021.01.16 16:52:24 5: 192.168.1.160: in cache, devices=shelly_1_98f4abf2883b (size=1)
2021.01.16 16:52:24 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#2, validity=3840, serial=3
2021.01.16 16:52:24 5: Found device shelly_1_98f4abf2883b, model shelly1
2021.01.16 16:52:24 5: cfgChanged = 2
2021.01.16 16:52:24 5: output_0 = 0
2021.01.16 16:52:24 5: input_0 = 0
2021.01.16 16:52:24 5: inputEvent_0 =
2021.01.16 16:52:24 5: inputEventCnt_0 = 0
2021.01.16 16:52:39 5: Received data from 192.168.1.160
2021.01.16 16:52:39 5: 192.168.1.160: in cache, devices=shelly_1_98f4abf2883b (size=1)
2021.01.16 16:52:39 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#2, validity=3840, serial=3
2021.01.16 16:52:39 5: Found device shelly_1_98f4abf2883b, model shelly1
2021.01.16 16:52:39 5: cfgChanged = 2
2021.01.16 16:52:39 5: output_0 = 0
2021.01.16 16:52:39 5: input_0 = 0
2021.01.16 16:52:39 5: inputEvent_0 =
2021.01.16 16:52:39 5: inputEventCnt_0 = 0
2021.01.16 16:52:54 5: Received data from 192.168.1.160
2021.01.16 16:52:54 5: 192.168.1.160: in cache, devices=shelly_1_98f4abf2883b (size=1)
2021.01.16 16:52:54 5: URI: /cit/s, global_devid = SHSW-1#98F4ABF2883B#2, validity=3840, serial=3
2021.01.16 16:52:54 5: Found device shelly_1_98f4abf2883b, model shelly1
2021.01.16 16:52:54 5: cfgChanged = 2
2021.01.16 16:52:54 5: output_0 = 0
2021.01.16 16:52:54 5: input_0 = 0
2021.01.16 16:52:54 5: inputEvent_0 =
2021.01.16 16:52:54 5: inputEventCnt_0 = 0


list des "fehlerhaften" Shelly:

Internals:
   CFGFN     
   DEF        192.168.1.146
   DURATION   0
   FUUID      60030ba8-f33f-19f1-dd02-9133f86bcceb4535
   INTERVAL   600
   NAME       shelly_1_98f4abf2883b
   NR         509
   SHELLYID   98F4ABF2883B
   STATE      Error
   TCPIP      192.168.1.146
   TYPE       Shelly
   READINGS:
     2021-01-16 16:52:12   network         not connected
     2021-01-16 16:52:09   relay           off
     2021-01-16 16:52:12   state           Error
Attributes:
   interval   600
   model      shelly1



"Fehlerhaftes" Shelly-Device gelöscht.
Tabelle stimmt wieder, also nur noch das eine Device mit der neuen IP.

Name geändert und Create -> Device wird angelegt. (Leider KEIN room / gut es ist ja über den ShellyMonitor-Link in der Tabelle einfach zu finden)


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

Dann Shelly 1L ins Netzwerk.
ID/Name in der Liste "eigenartig" (siehe ScreenShot).

Log:

2021.01.16 17:07:13 5: Received data from 192.168.1.138
2021.01.16 17:07:13 5: 192.168.1.138: in cache, devices=_84cca8adf59e (size=1)
2021.01.16 17:07:13 5: URI: /cit/s, global_devid = SHSW-L#84CCA8ADF59E#2, validity=3840, serial=2
2021.01.16 17:07:13 5: cfgChanged = 1
2021.01.16 17:07:13 5: output_0 = 0
2021.01.16 17:07:13 5: input_0 = 0
2021.01.16 17:07:13 5: inputEvent_0 =
2021.01.16 17:07:13 5: inputEventCnt_0 = 0
2021.01.16 17:07:13 5: input_1 = 0
2021.01.16 17:07:13 5: inputEvent_1 =
2021.01.16 17:07:13 5: inputEventCnt_1 = 0
2021.01.16 17:07:13 5: deviceTemp = 33.08
2021.01.16 17:07:13 5: deviceTemp = 91.55
2021.01.16 17:07:13 5: overtemp = 0



IP-Adresse geändert

Log:

2021.01.16 17:10:49 5: Received data from 192.168.1.161
2021.01.16 17:10:49 5: 192.168.1.161: in cache, devices=_84cca8adf59e (size=1)
2021.01.16 17:10:49 5: URI: /cit/s, global_devid = SHSW-L#84CCA8ADF59E#2, validity=3840, serial=2
2021.01.16 17:10:49 5: cfgChanged = 1
2021.01.16 17:10:49 5: output_0 = 0
2021.01.16 17:10:49 5: input_0 = 0
2021.01.16 17:10:49 5: inputEvent_0 =
2021.01.16 17:10:49 5: inputEventCnt_0 = 0
2021.01.16 17:10:49 5: input_1 = 0
2021.01.16 17:10:49 5: inputEvent_1 =
2021.01.16 17:10:49 5: inputEventCnt_1 = 0
2021.01.16 17:10:49 5: deviceTemp = 35.08
2021.01.16 17:10:49 5: deviceTemp = 95.15
2021.01.16 17:10:49 5: overtemp = 0



Device mit alter IP -> Create
"Selbes" Device mit neuer IP -> Create:

Log:

2021.01.16 17:13:22 1: AutoCreate called for IP 192.168.1.161, ip2devices=1
2021.01.16 17:13:22 1: AutoCreating shelly_1l returned shelly_1l already defined, delete it first


Ja, korrekt... ;)

Dann Device mit alter IP gelöscht.
Eintrag in Tabelle korrekt (bis auf "komischer" vorgeschlagener Name)...

-> Create angelegt ok.

EDIT: die IPs 160 / 161 sind die, die ich "dann" haben will/wollte...

Muss jetzt leider wieder ein paar andere Sachen machen.

@pah: gibt es etwas, dass ich bzgl. Shelly-Modul testen kann/soll?

Gruß, Joachim

Hi Joachim,

erst mal Danke!
Der "komische" Name kommt, weil ich zwar ein Model-Mapping für "SHSW-L" eingetragen hatte, aber keinen "Präfix" für den vorgeschlagenen Gerätenamen.

Den Usecase "noch nicht eingerichtetes Gerät zieht mit der IP um" habe ich nicht berücksichtigt. Aber sehr plausibel! Mal gucken, ob ich das heute noch verbessere.

Zitat von: gvzdus am 16 Januar 2021, 17:40:13
Mal gucken, ob ich das heute noch verbessere.

Eieiei...

Vielleicht habe ich dann auch noch mal Zeit/Lust zu testen...

Den RGBW2 habe ich ja noch nicht eingerichtet ;)

Morgen kann ich nicht...
...Montag muss ich mal sehen...

Evtl. ein "Löschen-Knopf" hinter jeden Eintrag?
Würde mir reichen...
Ansonsten müsstest du ja immer schauen unter welcher IP für die genannte ID denn zuletzt was gekommen ist...

Gruß, Joachim

Hallo und guten Abend

Frage: ich habe meine shellies (hauptsächlich plug-s) via mqtt2 an Fhem gebunden.
Ich habe das Modul installiert aber es werden nicht alles angezeigt. Ist das nur für das Shelly Modul geschrieben?
Gruß
helmut

Hi Helmut, die Geräte selber müssten Dir angezeigt werden, allerdings nicht als eingerichtet.
Ich habe überlegt, ob ich das Modul auch auf MQTT2 auslegen sollte. Da gibt es aber nicht viel zu tun: das Modul könnte nur helfen, die IP-Adresse eines neuen Gerätes zu identifizieren.
Daher ist es vornehmlich auf Mod_Shelly ausgelegt. Bei MQTT kriegst Du die Ohren auch ohne ShellyMonitor genauso blutig vollgequatscht :-)

Viele Grüße, Georg

So, erste Erfolgsmeldung: Die beiden Module vertragen sich prima, keine unnützen Logmeldungen.

Saubere Sache, gute Arbeit, Georg.

LG

pah

Ich bekomme noch ein Problem, wenn ich einen ShellyMon einrichten will

Can't use string ("Shelly%2d%3e1PM") as a HASH ref while "strict refs" in use at ./FHEM/36_ShellyMonitor.pm line 722.

Zitat von: bombardi am 18 Januar 2021, 13:47:46
Ich bekomme noch ein Problem, wenn ich einen ShellyMon einrichten will

Code Auswählen Erweitern

Can't use string ("Shelly%2d%3e1PM") as a HASH ref while "strict refs" in use at ./FHEM/36_ShellyMonitor.pm line 722.

https://forum.fhem.de/index.php/topic,117805.msg1122835.html#msg1122835

Gruß, Joachim