Hallo,
Nach einem Update auf die aktuelle Version (mit 10_CUL_HM v4416) hatte ich das Problem dass die Homematic-Komponenten zum Teil das falsche IODev verwenden (ich habe mehrere HMLANs definiert). Bei allen Komponenten habe ich das Attribut IODev gesetzt, nach einem Neustart von FHEM wird das Attribut unter Internals auch korrekt angezeigt um dann aber nach kurzer Zeit zu wechseln. Dadurch werden die Befehle über den falschen HMLAN rausgeschickt. Ich glaube dass das Problem von Zeile 2324 kommt:
AssignIoPort($defs{$devName}) if (!$defs{$devName}{IOdev});
Hier ist IOdev mit einem kleinen 'd' geschrieben, im gesamten restlichen Code und im Attribut aber mit einem großen 'D'. Ich habe die Zeile geändert, FHEM neu gestartet und das Problem scheint behoben.
Grüße,
ChrisD
Hi Chris,
ist ein Bug - deine Lösung ist absolut korrekt
Gruss Martin
Hallo,
habe das gleiche Problem und bin schon am verzweifeln - insbesondere da ich gerade von einer FB auf einen Raspberry umsteige -> da weiß ich dann nie, ob der Fehler durch den Umzug kommt oder was anderes falsch ist.
Chris:
Wie war deine Lösung? wo bzw. in welcher Datei muss ich das ändern?
Sascha
Hallo,
Der Fehler ist in der aktuellen Version 4435 von 10_CUL_HM.pm behoben, nach einem 'update' und Neustart sollte es wieder funktionieren.
Grüße,
ChrisD
ah, sehr gut - und wie finde ich die Version heraus? Habe jetzt zwar mal ein Update gemacht - will aber sichergehen, dass das funktioniert hat ;-)
Sascha
In der FHEM-Kommandozeile 'version' eingeben, wenn das Update funktioniert hat sollte da u.a. dies stehen:
Zitat# $Id: 10_CUL_HM.pm 4435 2013-12-21 13:59:29Z martinp876 $
Grüße,
ChrisD
super, hat funktioniert - herzlichen Dank - jetzt muss ich nur noch rausfinden warum die HM-CC-TC nicht richtig auf fhem reagieren - vielleicht muss ich jetzt nochmal pairen - bekomme einen IOerr ...
Sascha
Irgendwas passt leider immer noch nicht:
Ich habe im Wintergarten zwei Heizkörper - jeder mit einem HM-CC-VD. Beide sind gepeered an einen HM-CC-TC. Wenn ich jetzt bei den HM-CC-Vd den IODev auf HMLAN1 umstelle, vergessen diese die Einstellung wieder und verbinden sich mit HMLAN2 - obwohl die rssi des HMLAN1 sehr viel besser ist als die des HMLAN2 -woran liegt das?
Sascha
Hallo Sacha,
das Attribut IODev sollte nur automatisch geändert werden, wenn du pairst.
ist dein IODev im pairing-mode? Wird da etwas angezeigt im IODev? Irgendetwas mit hmPair?
RSSI wird nbei der Auswahl nicht berücksichtigt
Gruss Martin
Hallo Martin,
ich setze den HMLAN (IODev?) immer nur für 120 sec in den Pairing Modus dann paire ich den TC - bekomme ein "OK" - allerdings manchmal erst bei zweiten Versuch - oder ich muss den HMLAN mal kurz vom Strom nehmen - Dann setze ich händisch das IODev beim TC auf "HMLAN1". Dann ändert sich komischerweise das IODev von HMLAN 1 auf HMLAN2 - selbst wenn ich den HMLAN nicht in den Pairing Modus setzte und innerhalb von 1,5h zirka fünfmal auf MHLAN 1 umgestellt hatte????
Sascha
p.s.: wie sehe ich denn ob der HMLAN noch im pairing miodus ist - bei State steht bei beiden HMLANs "open"
wobei ich jetzt eine Idee habe - wie kann ich herausfinden, ob die VDs an den TC gepeert sind oder an fhem gepaired? Ich habe mal ein get .... regList gemacht - dort steht pairing to central? Bin mir aber recht sicher, dass ich damals, als ich den Raum eingerichtet hatte zuerst die beiden VDs mit dem TC verbunden hatte und diesen dann mit fhem gepaired hatte???
Hi Sascha,
das HMLAN muss nicht von Strom - es ist eine Sache der FHEM-SW.
Das HMLAN ist im pairing-mode wenn in block Internals hmPair = 1 gesetzt ist. Wenn du hmPairForSec 20 machst solltest du es 20 sekunden lang sehen können, dann muss es verschwinden.
Wenn du Anlernen zum Lesen oder Schreiben drückst solle hmPair nicht aktiv sein (ausser du willst pairen).
Gruss Martin
Hi martin,
komme einfach nicht weiter - will nicht dauernd nachfragen - aber ich scheitere schon daran "block Internals hmPair = 1 gesetzt ist" das herauszufinden - hab gegoogelt wie doof - aber ich finde dazu nix :-(
wenn ich unter "unsorted" auf HMLAN1 klicke, dann gibt es da nirgends den Begriff hmPair=1 ....
was ich bekomme ist
DeviceName
192.168.178.54:1000
FD
10
HMLAN1_MSGCNT
181
HMLAN1_TIME
2013-12-22 17:29:07
HM_CMDNR
17
NAME
HMLAN1
NR
36
NTFY_ORDER
50-HMLAN1
PARTIAL
RAWMSG
E1F6145,0000,00BE5F89,FF,FFC9,C486701F6145000000009449
RSSI
-55
STATE
opened
TYPE
HMLAN
XmitOpen
1
assignIDs
1F5E53,1D8C17,1D8B7A,1D8B73,1D9503,1F6145
assignIDsCnt
6
assignIDsReport
3
firmware
0.961
msgKeepAlive
dlyMax:0.015 bufferMin:4
msgLoadEst
1hour:3% 10min steps: 0/2/0/0/0/0
msgParseDly
min:4 max:186 last:5 cnt:150
owner
1E9DA6
serialNr
JEQ0707402
uptime
000 03:27:56.297
und
Xmit-Events
ok:1
2013-12-22 17:13:28
cond
ok
2013-12-22 17:13:28
prot_ERROR-Overload
last
2013-12-22 13:46:41
prot_Overload-released
last
2013-12-22 13:29:01
prot_Warning-HighLoad
last
2013-12-22 13:45:06
prot_disconnected
last
2013-12-22 17:13:27
prot_init
last
2013-12-22 17:13:27
prot_ok
last
2013-12-22 17:13:28
so,
bin ein Stück weiter:
Es scheint so zu sein (vielleicht ist das offensichtlich - ich wusste es aber nicht):
- die fhem.cfg ist so aufzubauen, dass zunächst der erste HMLAN (HMLAN1) definiert wird und dann alle Geräte die mit diesem Zusammenarbeiten einzutragen sind
- dann den zweiten HMLAN (HMLAN2) definieren und darunter dann alle Geräte die von diesem gesteuert werden sollen
Mit diesem Setup wechselt das IODev momentan (hoffentlich bleibt's so) nicht.
Kann das sein, dass dem so ist? Falls ja denke ich, dass sollte im Wiki zu HMLAN dokumentiert werden, damit andere Anfänger als ich es einfacher haben ;-)
Vielleicht ist das aber nur ein Zufall ....
Sascha
Zitat von: Sascha am 22 Dezember 2013, 19:01:31
so,
bin ein Stück weiter:
Es scheint so zu sein (vielleicht ist das offensichtlich - ich wusste es aber nicht):
- die fhem.cfg ist so aufzubauen, dass zunächst der erste HMLAN (HMLAN1) definiert wird und dann alle Geräte die mit diesem Zusammenarbeiten einzutragen sind
- dann den zweiten HMLAN (HMLAN2) definieren und darunter dann alle Geräte die von diesem gesteuert werden sollen
Mit diesem Setup wechselt das IODev momentan (hoffentlich bleibt's so) nicht.
Kann das sein, dass dem so ist? Falls ja denke ich, dass sollte im Wiki zu HMLAN dokumentiert werden, damit andere Anfänger als ich es einfacher haben ;-)
Vielleicht ist das aber nur ein Zufall ....
Sascha
ich hab auch 2 hmlan in betrieb, kann aber deine Prob nicht nachvollziehen :o , die sind ganz am anfang nach den globals definiert.
Zitatdefine tPort telnet 7072 global
define hmlan1 HMLAN 192.168.2.80:1000
attr hmlan1 hmId xxxxxx
attr hmlan1 hmLanQlen 1_min
attr hmlan1 wdTimer 25
#attr hmlan1 hmProtocolEvents 1
define hmlan2 HMLAN 192.168.2.81:1000
attr hmlan2 hmId xxxxxx
attr hmlan2 hmLanQlen 1_min
attr hmlan2 wdTimer 25
#attr hmlan2 hmProtocolEvents 1
#define CUL2 CUL /dev/ttyACM0@38400 xxxx
#attr CUL2 rfmode HomeMatic
#attr CUL2 hmProtocolEvents 1
und wenn ich über attr IODev einem device den hmlan(1/2) zuweise bleibt das auch. und save nicht vergessen! damit es in die fhem.cfg geschrieben wird.
ZitatInternals hmPair = 1
erscheint bei mir wenn ich hmPairForSec 20 eingebe für 20 sekunden unter dem Hmlan den es betrifft,in dem Kasten INTERNALS, danach ist es wieder weg.
genau so wie es Martin beschrieben hat.
Wie machst du das mit dem SAVE - ich weise die IODev über den Button |attr| Wandthermostat_Wintergarten |IODev| HMLAN1 zu und drücke dann <Return> - da ist nirgends was für <save> ?
Und wie gesagt - seit meiner Umstellung funktioniert es bei mir - warum auch immer
Das mit dem hmPair = 1 hab ich gerade mal getestet - erscheint bei mir ebenfalls wenn ich set HMLAN1 hmPairForSec 60 eingebe - das war vorhin nicht da - i.e. die HMLAN waren nicht im Pairing Modus und trotzdem hat sich die IODev Zuordnung permanent geändert. Weil hmPair=1 nur beim Pairen erscheint habe ich es nicht gefunden - ich hatte vermutet, dass der Wert dann halt hmPair=0 ist wenn der HMLAN nicht im Pairingmodus ist
Sascha
"save " kein geschrieben!
in die komandozeile und return drücken
erst dann ist es in der fhem.cfg
danke dir -wieder was gelernt ;-)
Sascha