FHEM Start und Definition von IO Devices

[betateilchen]

man müsste vor dem speichern nur alle devices durch gehen und an hand des IODev internals jeweils alle devices die zu einem iodev gehören zusammen suchen und dann jeweils zuerst das iodev und alle zugehörigen devices speichern und dann mit dem nächsten iodev weiter machen. und danach den ganze rest.

Hatte ich seinerzeit schon genau so probiert, aber das hat nicht zuverlässig funktioniert (warum, weiss ich nicht mehr genau).
Genau deshalb kam damals die Idee mit der "Selbstkennzeichnung" von IOdevices.

[justme1968]

man muss auf jeden fall von den aktuell bei den clients eingetragenen iodev aus gehen und diese jeweils gruppiert mit den zugehörigen clients abspeichern.

wenn man umgekehrt nur von den generell möglichen clients eines iodev aus geht bringt man installationen durcheinander die mehrte gleiche iodevs haben und die clients nicht im
define fest eingetragen sind. das ist die große mehrheit. fs20, it und auch hm ohne vccu.

aus diesem grund kann man auch nicht einfach alle iodevs zusammen an den anfang sortieren.

vielleicht fällt dir noch ein was damals nicht funktioniert hat.

[betateilchen]

Ich habe mir jetzt eine Funktion gebaut, die mir drei Ergebnisse liefert:

Ein array mit allen in Clients gefundenen IODevs

Code Auswählen Erweitern


2016.12.18 20:25:48.007 1: DEBUG>$VAR1 = [
          'hmuart'
        ];


Einen hash1 mit devicename und zugehörigem IODev

Code Auswählen Erweitern


2016.12.18 20:25:48.009 1: DEBUG>$VAR1 = {
          'sz_Bett_links' => 'hmuart',
          'ez_Sensor' => 'hmuart',
          'wz_RT' => 'hmuart',
          'az_Ventilator' => 'hmuart',
          'az_RT' => 'hmuart',
          'Melder_Klingel' => 'hmuart',
...


Einen hash2 mit allen devices ohne IODev

Code Auswählen Erweitern


2016.12.18 20:25:48.016 1: DEBUG>$VAR1 = {
          'PegelHH' => 'noiodev',
          'sz_RT_ClimaTeam' => 'noiodev',
          'Gruppe_F' => 'noiodev',
...


Als nächstes muss ich mir eine Logik bauen, um einzelne devices zu speichern.

Dann ein loop über das erstgenannte Array und in dieser Schleife
- zuerst das IODev sichern
- alle Geräte aus hash1 sichern, die dieses IODev verwenden.

Im letzten Schritt alle Geräte ohne IODev aus hash2 sichern.


Soweit richtig gedacht?

[rudolfkoenig]

Da fhem.pl inzwischen das IODev Attribut automatisch setzt in AssignIoPort (bis auf CUL_WS), ist vermutlich die Reihenfolge der IODevs beim Schreiben egal. Ich habe trotzdem noch Respekt vom automatisches Umsortieren, die Kommentare werden sinnlos, vmtl. gibt es auch andere Nebeneffekte, die erst in ein paar Wochen auftauchen.

Ich wuensche mir, dass wir vorher die Problemfaelle klar beschreiben, und nicht nur ein eingebildetes Problem loesen. Der TE hat  nur eine Frage gestellt, und kein Problem beschrieben.

[justme1968]

probleme:
- anwender tauscht ein iodev gegen ein neues aus. d.h. das neue wird ganz normal per define angelegt, alle IODev attribute von hand umgesetzt, das alte gelöscht und getestet -> erst mal läuft alles. aber beim nächsten neustart gibt es ein problem.

@betateilchen: durch das zusammen suchen über die hashes wird die reihenfolge komplett umgeschmissen.

wie wäre folgendes:
- hash1 wie oben vorgeschlagen erzeugen
- die schleife bleibt wie bisher mit folgenden änderungen:
  - wenn das aktuelle device (als iodev) in hash1 enthalten ist -> aus hash1 löschen
  - wenn das aktuelle device ein iodev hat das in hash1 enthalten ist -> zuerst das iodev sichern, dann das device

damit würde die reihenfolge im grossen und ganzen beibehalten, nur die ios werden jeweils vor das erste device sortiert das sie verwenden falls die reihenfolge nicht passt.

[betateilchen]

@Rudi: keine Sorge. Es geht mir mehr um die Machbarkeit selbst, weil mich das Thema schon lange ärgert. Die fhem Welt besteht nämlich nicht nur aus fhem.cfg

@Andre: danke für die Hinweise. Werde ich mal überlegen.

[Thorsten Pferdekaemper]

Hi,
gibt es zu dem Thema inzwischen eigentlich neue Erkenntnisse? Es scheint doch das ein oder andere Problemchen zu geben, wenn z.B. ein IO-Device ausgetauscht werden soll.
Ich bin mir nicht ganz sicher, ob das Problem grundsätzlich nur für IO-Devices auftritt, oder auch für andere Devices, die irgend eine "Basis" voraussetzen. Ich habe jetzt grad das Beispiel nicht im Kopf, aber ich glaube, das war irgendwas mit PRESENCE.
Gruß,
   Thorsten

[rudolfkoenig]

Ich empfehle:
- der ModulAutor soll erst dann IOWrite verwenden, wenn die Initialisierung abgeschlossen ist. Das kann man mit notify auf global:INITIALIZED oder mit InternalTimer(1, ...) erreichen. Dann werden die per Attribut gesetzten IODevs auch beruecksichtigt.
- der Benutzer soll nach Austausch des IODevs die IODev Attribute anpassen, z.Bsp. mit "attr IODev=CUL_alt IODev CUL_neu"

[Thorsten Pferdekaemper]

Hi,
danke für die rasend schnelle Antwort. Das bedeutet, dass die Modulautoren das Problem lösen sollen und man keine Annahmen über die Reihenfolge der Gerätedefinition machen sollte. Dann muss ich das auch mal für HM-Wired reparieren...
Gruß,
   Thorsten

[betateilchen]

- der Benutzer soll nach Austausch des IODevs die IODev Attribute anpassen, z.Bsp. mit "attr IODev=CUL_alt IODev CUL_neu"

denn dann werden die Geräte neu durchnummeriert, sodass die "versorgten" Geräte eine höhere Nummer bekommen als das neu angelegte IODev selbst.

Allerdings ist mir noch nicht ganz klar, warum ich inzwischen {NR} Werte weit im 5-stelligen Bereich in meinem System habe. Irgendwie scheint es mir, als würden die Geräte viel zu oft neu durchnummeriert.

[rudolfkoenig]

denn dann werden die Geräte neu durchnummeriert

Stimmt, kann aber nicht mehr begruenden, wieso. Ich finde, diese Umnummerierung sollte entfernt werden.

Die automatische Zuordnung finde ich sinnvoll, damit der Benutzer nicht verpflichtet ist, das explizit zu tun. Das logische Modul darf aber nicht vor der Zuweisung der Attribute das IODev verwenden, da eine automatische Zuordnung nicht immer richtig ist.

[betateilchen]

Stimmt, kann aber nicht mehr begruenden, wieso.

Weil beim Speichern der Konfiguration die Geräte nach Nummern aufsteigend sortiert und (ohne die Nummer) gespeichert werden.
Durch die Umnummerierung wird weitgehend sichergestellt, dass beim FHEM Start kein Gerät vor seinem zugehörigen IODev definiert wird.

Ich finde, diese Umnummerierung sollte entfernt werden.

Ich auch. Wobei mir ja grundsätzlich egal ist, ob meine 350 Geräte von 1-350 oder von 1-27934 durchnummeriert sind. Es war mir nur aufgefallen, dass ich seit einiger Zeit sehr hohe Nummern im System habe.

[rudolfkoenig]

Habe die Umnummerierung entfernt.

[Thorsten Pferdekaemper]

Hi,
ich bin jetzt soweit, das Problem für HM485 anzugehen. Meine Devices haben auch das Attribut IODev, aber fhem.pl liefert mir diese Meldung, wenn das IODev vorher noch nicht definiert ist:

Code Auswählen Erweitern


configfile: HBW_Sen_Key_12_HBW7296279: unknown IODev hm485 specified

Das Attribut wird dann nicht gesetzt. D.h. ich habe dann auch keine echte Chance, mit den IOWrites zu warten, da mir das IODev komplett verloren geht. Ein AssignIoPort ist auch nicht viel besser, da das natürlich auch kein gültiges Device bekommt:

Code Auswählen Erweitern


No I/O device found for HBW_Sen_Key_12_HBW7296279


Ich könnte jetzt natürlich mein IODev in einem anderen Attribut oder einem Internal parken und dann später AssignIoPort aufrufen, aber das ist nicht wirklich schön.
Wie ist das denn jetzt gedacht?

Gruß,
    Thorsten

[rudolfkoenig]

fhem.pl liefert mir diese Meldung, wenn das IODev vorher noch nicht definiert ist:

Ich gehe davon aus, dass dein fhem.pl nicht aktuell ist. Siehe auch https://forum.fhem.de/index.php/topic,69591.msg611353.html#msg611353
Bei mir liefert folgende Reihenfolge keinen Fehler beim starten:

Code Auswählen Erweitern

define FS20 FS20 1234 56
attr FS20 IODev CUL
define CUL CUL none 0000