assignIDs bei gleichzeitigem Betrieb von HMlan und HMusb - Problem !?

olisba · 04 Januar 2014, 16:46:47

Hallo zusammen,

ich habe im EG einen HMlan im LAN, und im Keller an der Fritzbox noch einen HMusb.

Beim Pairen der Devices habe ich immer nur einen der beiden Adapter in den Pairing-Mode gesetzt. In Summe sind
- am HMlan:
13 Heizkörperthermostate HM-CC-RT-DN
10 Fensterkontakte HM-SEC-SC
- am HMusb
3 FEnsterkontakte

gepairt.

Im Prinzip funktioniert inzwischen auch alles (bis auf Peeren der Thermostate, aber das ist anderes Thema).
Mir ist zwar aufgefallen, daß einzelne Fensterkontakte manchmal auch Rot melden, aber i.d.R. mit Grün beenden. Status usw. wird auch im FHEM korrekt angezeigt, keine Fehlerhaften Kommandos. Paired-To ist auch immer korrekt in den Sensoren bzw. Thermostaten eingetragen (d.h. bei den 3 Fensterkontakten im Keller auch die Korrekte HM-ID des HMusb.

Jetzt ist mir gerade - zufällig - aufgefallen, daß es im FHEM in der Ansicht der zwei HMLAN devices (bei mir HMlan1 und HMusb1) jeweils unter "internal" den Parameter "assignIDs" gibt.
Da stehen jetzt komischerweise nicht alle HM Komponenten IDs drinnen, die ich erwarten würde.
Laut FHEM Commandref sollten da (wenn ich's richtig verstehe) alle angelernten devices stehen.
Bei mir stehen beim HMlan1 nur 4 device IDs, und beim HMusb1 nur 3 Stück. Noch "schlimmer", die 3 IDs beim HMusb1 stehen auch im HMlan1, d.h. sind doppelt.

Meine Frage: sehe ich das richtig, daß das FHEM durcheinanderbringen kann wenn die devices da doppelt drin stehen in zwei versch. Adaptern? Sollten nicht alle devices die (lt. device reading) korrekt gepairt wurden auch in einem der beiden Adapter unter assignIDs gelistet sein ?
Kann man die device Einträge da manuell korrigieren?

Falls es hilft bzw. etwas damit zu tun haben könnte: ich hatte auch mal den FHEM stand drauf vor Weihnachten, bei dem es den Fehler bzgl. IODev gab (hatte bei mir auch alle IODev Einträge in den Devices durcheinandergebracht (device Einträge hab ich danach manuell korrigiert über set IODev ... ).
Zur Zeit ist der aktuellste SW stand per "update" installiert, läuft auf einer Fritzbox 7390.

Danke für eure Hilfe, und v.a. Danke an alle Entwickler der FHEM SW, macht echt Spaß

!

Gruß,
Oli

martinp876 · 04 Januar 2014, 17:26:34

Hallo Oli,

einem IO device werden vor dem Senden die IDs bekanntgegeben (assigned). Ich gehe also davon aus, dass du nach dem letzten neustart mindestens eine message an die entsprechenden IDs über das jeweilige IO gesendet hast. Korrekt?

Bei mehreren IOs (eigentlich besser immer) solltest du festlegen, wer über welches IO senden soll. Das machst du (nicht über set sicher tipfehler sonder )
attr <dev> IODev

Welche IDs assigned sind kann ich nicht abfragen - daher wird nach restart neu gezählt. Es könnte sein, dass noch Reste im HMLAN/USB stehen, wenn es keinen reset des IO gegeben hat.

Beim Wechsel des IO devices wird bisher das Device nicht "de-assignd".
IDs werden erst assigned wenn FHEM etwas senden will. Es ist also nicht notwendig, alle IDs assigned zu haben.

Hier also die Fragen
- Verwendest du die gleiche HMId bei beiden IO devices?
- tritt das doppelt-Problem immer noch auf, wenn du jedem Device ein IODev attribut gibst? (channels natürlich nicht)

Gruss Martin

olisba · 04 Januar 2014, 20:06:34

Zitat von: martinp876 am 04 Januar 2014, 17:26:34

Hier also die Fragen
- Verwendest du die gleiche HMId bei beiden IO devices?
- tritt das doppelt-Problem immer noch auf, wenn du jedem Device ein IODev attribut gibst? (channels natürlich nicht)

Gruss Martin

Hallo Martin,

ja, attr und nicht set, war Schreibfehler.

HMId sind unterschiedlich für die zwei IO devices, darauf hatte ich geachtet.
Ich habe allen Devices ein IODev attritub gegeben (auch um nach dem o.a. Fehler die config wieder hinzukriegen).

Frage - vielleicht habe ich IODev auch falsch gesetzt:
Wenn ich meine HMInfo Instanz einen configCheck machen lasse, kommt für jedes Device eine Zeile wie :

PairedTo missmatch to IODev
DG_Ankleide_Fenster paired:0x123456 IO attr: 123456

das IODev setzen habe ich über den Namen, nicht die numerische ID gemacht - war das vielleicht ein Fehler ?
Also konkret steht z.B. in o.A. Fenster Kontakt unter "Attributes" : IODev mit Inhalt: HMlan1 (und nicht 0x123456 oder auch 123456).
(erzeugt über "attr DG_Ankleide_Fenster IODev HMlan1 " )

Korrekt oder falsch ?

Gruß,
Oli

martinp876 · 04 Januar 2014, 20:19:35

Hallo Oli,

Im Prinzip sollte es korrekt sein:
- 2 IOs mit unterscheidlichen IDs
- devices paired
- attr IODev jeweils gesetzt auf das IO, mt dessen ID es gepairt ist.
- im IODev muss der Name stehen, nicht die HMId

verstehe ich nicht:

ZitatDG_Ankleide_Fenster paired:0x123456 IO attr: 123456

kann es sein, dass ein blank in der HMId des IO versteckt ist?
Ist mir aktuell nicht klar, warum es als mismatch angezeigt wird.

Gruss Martin

olisba · 04 Januar 2014, 20:47:40

Danke,

dann ist's vielleicht ein Fehler vom HMInfo:
In den Device Readings wird nämlich bei "PairedTo" auch die Nummer mit "0x" davor angezeigt, also wenn meine ID 123456 wäre, dann wird dort 0x123456 angezeigt.
DAs gleiche bei 0x bei "R-pairCentral".
Wenn er das jetzt mit HMlan1 (was def. ist mit "attr HMlan1 hmId 123456") vergleicht, stört ihn evtl. das 0x . Was ich meine, vielleicht stolpert er beim vergleich verschiedener Datentypen ohne es zu merken?

Gruß,
Oli

martinp876 · 05 Januar 2014, 09:04:33

Hi Oli,

das 0x (für hex) steht immer drin und ist berücksichtigt. Das sollte nicht das Problem sein - ist bei mir immer so und wird nicht alarmiert.
bei wie vielen deiner Geräte pasiert dies?

Gruss Martin

olisba · 05 Januar 2014, 09:54:59

Hallo Martin,

HMinfo meldet das für alle ! Devices.

Meine ursprüngliche Frage bzgl. assignedIDs ist aber kein Problem, wenn ich dich richtig verstanden habe, entstehen die Einträge dort durch FHEM beim mithören, d.h. Es ist kein Konfigurationsparameter, sondern eher nur Info, richtig?

Gruß,
Oli

tpm88 · 05 Januar 2014, 12:35:46

Hallo Martin,

bei mir zeigt der config check nach dem heutigen Update und Restart ebenfalls für alle HM Devices den IODev mismatch an:

Code Auswählen


configCheck done:

 PairedTo missmatch to IODev
    az_Thermostat paired:0xF11034 IO attr: -
    az_podFS1010 paired:0xF11034  IO attr: -
    dg_Thermostat paired:0xF11034 IO attr: -
    ke_Pumpe paired:0xF11034 IO attr: -
    ke_Switch4 paired:0xF11034 IO attr: -
    ku_Switch1 paired:0xF11034  IO attr: -
    wz_Markise paired:0xF11034 IO attr: -
    wz_Thermostat paired:0xF11034 IO attr: -

Als IO Dev für alle HM Devices habe ich nur einen CUL:

Code Auswählen

list CUL_HM

Internals:
   CMDS       BCFiAZEGMRTVWXefmltux
   CUL_HM_MSGCNT 41
   CUL_HM_TIME 2014-01-05 12:31:50
   Clients    :CUL_HM:HMS:CUL_IR:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         11
   FHTID      1034
   HM_CMDNR   12
   NAME       CUL_HM
   NR         35
   PARTIAL    
   RAWMSG     A0F32861021DE950000000A90BF1000583B
   RSSI       -44.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.55 CUL868
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
   Readings:
     2013-11-04 00:26:27   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2014-01-05 12:12:26   cmds             B C F i A Z E G M R T V W X e f m l t u x
     2013-11-04 00:25:41   raw             ? (ccconf is unknown) Use one of B C F i A Z E G M R T V W X e f m l t u x
     2014-01-05 12:31:50   state           Initialized
   Helper:
     14ea42:
       QUEUE:
     1dda0d:
       QUEUE:
     20b055:
       QUEUE:
     20f526:
       QUEUE:
     21729a:
       QUEUE:
Attributes:
   rfmode     HomeMatic
   room       Interfaces

Ein getConfig auf die Devices bringt keine Änderung.

Aktive Versionen:

Code Auswählen

# $Id: fhem.pl 4519 2014-01-01 15:43:32Z rudolfkoenig $
# $Id: 00_CUL.pm 4530 2014-01-02 13:56:09Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4560 2014-01-04 16:01:09Z martinp876 $
...
# $Id: 98_HMinfo.pm 4520 2014-01-01 19:05:41Z martinp876 $

Gruss,
Tobias

martinp876 · 05 Januar 2014, 19:07:07

Hallo Tobias,

das halte ich auch für korrekt.....
Ein IO device für HM muss eine HM ID nutzen, die im Attribut hmId angegeben wird. Dies fehlt bei dir

in der orginal SW (von Rudi denke ich) gab - und gibt es noch - einen automatismus, der das port aus eine CUL-definition nutzt und 2 character addiert "F1". Somit läuft das ganze.

Ich werde es nicht abschalten, aber auch nicht unterstützen. m.E. muss der User diese ID wissentlich festlegen. Wenn hier eine Fehlermeldung kommt ist es genau richtig.

In deinem Fall solltest du

Code Auswählen

attr CUL_HM hmId F11034
setzen. das ist die ID zu der deine Devices gepairt wurden.

Gruss Martin

tpm88 · 06 Januar 2014, 00:30:07

Hallo Martin,

danke für die - wie immer - kompetente Antwort.

Nach Setzen der hmId ist jetzt der HMinfo config check wieder sauber.

Ich habe im Backup nachgesehen - das Attribut ist nicht durch den gestrigen Update verlorengegangen, hat also vorher auch nicht existiert. Vor dem Update war der config check aber sauber. Das bedeutet also, wenn ich es richtig verstehe, die IOdev mismatch Meldung ist also relativ neu in HMinfo aufgenommen worden??

Gruß,
Tobias

martinp876 · 06 Januar 2014, 10:50:55

Hi Tobias,

ich versuche ein configCheck weiter zu komplettieren. Der Check, ob ein IO device eingetragen ist und ob es das scheinbar korrekte ist ist neu.

Wie gesagt: bei CUL errechnet FHEM eine default-ID automatisch. Das ist nicht von mir, und ich halte es für nicht sinnvoll einen solch wichtigen Parameter implizit zu nutzen. Will sagen, es ging evtl. vorher auch ohne das Attribut, war aber nicht 'sauber' definiert.

Gruss Martin