Hi Leutz,
ich habe eine Frage zur Vorgehensweise bei der Verpaarung der Homematic Komponenten.
Bestandsaufnahme:
in zwei Räumen je 1x : HM-TC-IT-WM-W-EU Funk-Wandthermostat, HM-Sec-SCo Fensterkontakt optisch, HM-CC-RT-DN Heizkörperthermostat.
Diese Geräte hatte ich schon vor FHEM je Raum untereinander gepaart, wie auch immer mit meinem Eigenbau Cul-Stick sind sie inzwischen auch gepaart, aber so richtig rund löppt dat net.
Bevor ich jetzt bei allen Geräten die Paarungen zurücksetzt und anfange sie neu zu Paaren, hier die Frage nach der richtigen Reihenfolge.
1. Wenn ich es richtig verstanden habe, paart man als erstes alle Komponenten mit FHEM, egal in welchem Raum sie installiert sind.
2. Dann muss man sie aber in FHEM den richtigen Räumen zuordnen, damit der Schlafzimmer Fensterkontakt nicht die Wohnzimmerheizung steuert. Wie?
3. Sollte FHEM mal ausfallen, wissen die Komponenten noch wer zu wem gehört? oder paart man die extra untereinander?
4. Kann ein Temperatursensor der nicht von Homematic stammt, auch zur Regelung der Heizkörper genommen werden, z.B. ein DS18B20 der am GPIO hängt? .... Wenn ja, wie?
Vielen Dank im voraus ......
Hallo Mike,
1. Die Reihenfolge ist egal, man kann Kompenenten untereinander peeren und dann mit einer Zentrale pairen oder erst mit der Zentrale pairen und dann über die Zentrale untereinander peeren. Mit einer Zentrale gepairte Komponenten kann man nur noch mit Hilfe der Zentrale untereinander peeren. Peering bleibt beim Pairen erhalten. Das ist die Kurzform von dem was im Wiki steht. https://wiki.fhem.de/wiki/HomeMatic
2. Räume spielen dabei keine Rolle, man verbindet Komponenten direkt, die wissen nichts von Räumen.
3. Peering ist unabhängig von FHEM
4. Geht, allerdings nicht ohne FHEM. Dazu gibt es hier gefühlt hundert Artikel.
Gruß Otto
Hallo Otto,
mal sehen ob deine Antwort und die Wiki bei mir angekommen sind.
Als erstes werde ich mir eine eigene mhID geben.
1. werde ich all meine Komponenten nur mit FHEM pairen. (Raumzuordnung habe ich noch nicht verstanden)
2. werde ich die Komponenten, jeweils innerhalb eines Zimmers, in ihren Funktionen (chan) aus FHEM heraus peeren. (ist damit auch in FHEM die Zuordnung geregelt?)
3. bei einem FHEM-Ausfall sind die Komponenten entsprechend des peerings aus Punkt2 immer noch richtig verbunden und funktionieren dann autark.
4. okay, das werde ich mir dann raus suchen, dennoch eine Frage dazu,
sollte FHEM mit einem so eingebundener Sensor ausfallen, dann gehe ich davon aus, dass dann die Regel aus Punkt 3 greift.
Nochmal zum Verständniss.
a. Solange FHEM als HM-Zentrale fungiert, melden alle HM-Sensoren an FHEM und FHEM steuert dann entsprechend die HM-Aktoren. (die steuern sich nicht untereinander an FHEM vorbei)
b. Bei einem FHEM Ausfall gibt es keine HM-Zentrale mehr und die HM-Komponenten steuern sich ihrem peering entsprechend untereinander.
Ich glaube wenn ich das sauber ans Laufen gebracht habe, werde ich eine Step by Step Anleitung für die Nachwelt verfassen :-)
Genau, bleibe mal bitte bei "pairen" und "peeren" - zuviel Deutsch stiftet nur Verwirrung 8). Die korrekteren Übersetzungen wären (nach Homematic-Sprachgebrauch) "anlernen" für pair (Gerät<->Zentrale) und "(direkt)verknüpfen" für peer (Gerät <-> Gerät).
ZitatAls erstes werde ich mir eine eigene mhID geben.
Meinst Du HMID (HomeMatic-ID)? Die bekommt nur Dein CUL im Homematic-Modus, bzw. besser die zugehörige VCCU. Diese ID wird bei den Homematic-Geräten als Zentrale hinterlegt. Eine nachträgliche Änderung ist gleichbedeutend mit komplett neuem Anlernen (pairing). Wenn die alte Zentrale zuvor nicht "abgelernt" hat (unpair), klappt das Neuanlernen vielleicht nicht einmal mehr ohne kompletten Reset-
Dann:
Es gibt keinen Grund, ein bestehendes Peering aufzulösen. FHEM kann es aus den Daten der Geräte erkennen und anzeigen.
zu a.): Nein, gepeerte Geräte reden immer direkt miteinander, egal ob FHEM läuft oder nicht. FHEM liest die Kommunikation praktisch nur mit.
Sind Geräte nicht gepairt (an einer Zentrale angelernt), regeln sie das Peering (die Verknüpfung) bei einer Einrichtung allein untereinander - das musst Du mal so gemacht haben, das ist die Sache mit den Konfigurationsmodi in der Bedienungsanleitung.
Sind Geräte einmal gepairt, machen sie
Verknüpfungen untereinander nicht mehr, sondern akzeptieren diese Befehle nur noch von der Zentrale. Der normale Datenverkehr läuft aber weiterhin direkt zwischen den Geräten.
zu 1.: Die Raumzuordnung ist eine FHEM-interne Anordnung und hat nichts mit der Funktion der Geräte zu tun, wie Otto schon sagte. Bitte nicht verwechseln mit den Gruppen oder Gewerken in einer CCU2.
zu 2. siehe oben, wenn keine Neuzuordnung nötig, einfach so lassen
zu 3. funktionieren immer autark
zu 4. erübrigt sich demzufolge.
Was hat Volker jetzt nicht beantwortet?
b: ja :)
Gib mal zum besseren Verständnis ein list von deinem CUL und ein list von einem deiner HM Geräte
Dann brauchen wir nicht wegen der HMID der Zentrale zu rätseln.
Gruß Otto
Hi Leutz,
okay, dann war ich mehrfach auf einem falschen Dampfer.
Rückblende:
Ich hatte bei der Erstinstallation nur Heizkörperthermostat und Fensterkontakt, diese beiden habe ich direkt mit einander bekannt gemacht, ohne eine Zentrale, direkt die Pairingfunktion an den beiden Geräten genutzt, das ist demnach peering. Später ist das Wandthermostat dazu gekommen, wurde auch ohne zentrale bekannt gemacht. Das hat schon nicht gut funktioniert, da ich den Fensterkontakt schon mit dem Heizkörperthermostat verbunden hatte, passiert bei Öffnen des Fensters .... das Heizkörperthermostat geht sofort auf 12° und das Wandthermostat stellt das Heizkörperthermostat wieder auf die Solltemperatur von 20° zurück. Alleine daher, will ich allen Sensoren und Aktoren und FHEM Resetten bzw. für einen absoluten Neustart vorbereiten.
Wie ich die einzelnen HomeMatic Geräte in den Auslieferungszustand bringe, kann ich deren Anleitung entnehmen. Wie ist es bei FHEM, reicht es alle HomeMatic-Einträge aus der fhem.cfg zu löschen?
Ja, ich meinte die MomeMatic-ID
okay, gehen wir also davon aus, das alle HM-Geräte und FHEM resettet sind und nichts mehr voneinander wissen.
Dann paire ich ein HM-Gerät nach dem anderen mit FHEM.
Befehl: "set <CUL-Name> hmPairForSec 60" und Pairfunktion am HM-Gerät aktivieren.
jedes HM-Gerät, Eines nach dem Anderen, FHEM legt sie über autocreate an.
Danach sind alle HM-Geräte mit FHEM gepairt.
Um die Sache zu vereinfachen, gehen wir von nur einem Raum aus, mit einem Heizkörperthermostat, einem Wandthermostat und einem Fensterkontakt, die alle schon mit FHEM gepairt sind.
Jetzt die drei Geräte untereinander peeren.
Das Heizkörperthermostat bekommt vom Wandthermostat die Ist- und Solltemperatur so wie die WindowRec gepeert
Befehl dazu:
set Wandthermostat_Weather peerChan 0 Heizkörperthermostat_Weather single set
set Wandthermostat_Climate peerChan 0 Heizkörperthermostat_Climate single set
Den syntax für den Befehl wie das Wandthermostat die WindowRec an das Heizkörperthermostat peert habe ich noch nicht gefunden. (Hilfe)
Das Heizkörperthermostat bekommt vom Fensterkontakt ebenfalls die WindowRec gepeert (falls das Wandthermostat einmal ausfallen sollte)
set Fensterkontakt peerChan 0 Heizkörperthermostat_WindowRec single set
Wenn ich es richtig verstanden habe, gibt es eine Hierarchie, Einstellungen am Wandthermostat übersteuern Einstellungen am Heizkörperthermostat.
Beispiel: eingestellt ist 20° Wand und Heizköper zeigen 20° an, ich stelle am Heizkörperthermostat 18° ein, aber das Wandthermostat stellt das Heizkörperthermostat wieder auf 20° zurück.
oh, vergessen,
das Wandthermostat muss ja auch die Info vom Fensterkontakt bekommen.
sollte doch so aussehen:
set Fensterkontakt peerChan 0 Wandthermostat_WindowRec single set
dann noch eine Frage zu Single Set, das habe ich auch schon ohne Set gelesen, also nur single am Ende des set Befehls, wo ist der Unterschied?
Zitat von: CatWeazle am 19 November 2017, 15:12:35
dann noch eine Frage zu Single Set, das habe ich auch schon ohne Set gelesen, also nur single am Ende des set Befehls, wo ist der Unterschied?
Keiner. Default ist "dual set", single setzt auf Einkanal, bleibt set als default. unset löscht die Verknüpfung.
Sonst, wenn ich nichts übersehen habe, zu allem JA. Wandthermostat überschreibt Heizkörper, dauert aber u.U. ein paar Minuten.
Ach so: Bitte gewöhne Dir das Ändern der fhem.cfg erst gar nicht an. Lösche die Geräte aus ihrer Definition heraus (also wenn Du die Details des Gerätes siehst) mit dem Link unterhalb der Atrribute. Ein "save" in der Kommandozeile macht dann die Änderungen in der fhem.cfg endgültig. Alles andere sorgt immer wieder für undefinierte Probleme.
Denk daran, dass gerade die Heizkörperthermostate lange brauchen, bis sie die Anforderungen verarbeiten (mehrere Minuten sind normal) und dass die Fensterkontakte auch "behandelt" werden müssen, also beim SCo auf den Knopf drücken.
P.S.: die sig verstehe ich nicht. Schreibfehler?
Okay, bedankt.
dann habe ich es jetzt scheinbar im Groben verinnerlicht.
Durch deinen Satz:
Sind Geräte einmal gepairt, machen sie Verknüpfungen untereinander nicht mehr, sondern akzeptieren diese Befehle nur noch von der Zentrale. Der normale Datenverkehr läuft aber weiterhin direkt zwischen den Geräten.
ist mir jetzt auch klar, warum ich die Geräte untereinander nicht mehr peeren kann. also ohne FHEM, Gerät zu Gerät.
Gut, dann kann ich aber auch ohne alles zu resetten, alle peers von FHEM aus löschen und neue Verbindungen per SET Befehl zwischen den Gräten etablieren.
Das würde die Sache vereinfachen. Kann man z.B. mit HMinfo die Geräte fragen, welche peers bestehen ? damit man weiß, welche peers bei welchem Gerät gelöscht werden muss, bevor man sie neu peert?
und zu guter Letzt, ich lese immer vom peerChan 0, gibt es auch einen peerChan 1 oder 2,3,4 ?
beste Grüße
Denkste, so leicht war es dann doch nicht ....
set HM_56AD6A peerChan 0 HM_587E60_WindowRec single set
ergibt:
Unknown argument peerChan, choose one of assignHmKey clear clear deviceRename fwUpdate getConfig getRegRaw peerBulk raw regBulk regSet reset sign unpair virtual
Da werde ich weiter lesen müssen, wie es denn geht .....
Trotzdem schon mal vielen Dank
Zitat von: CatWeazle am 19 November 2017, 17:26:29
Denkste, so leicht war es dann doch nicht ....
set HM_56AD6A peerChan 0 HM_587E60_WindowRec single set
ergibt:
Unknown argument peerChan, choose one of assignHmKey clear clear deviceRename fwUpdate getConfig getRegRaw peerBulk raw regBulk regSet reset sign unpair virtual
Da werde ich weiter lesen müssen, wie es denn geht .....
Trotzdem schon mal vielen Dank
HM_56AD6A ist ein Device und kein Channel/Kanal, daher kennt das Gerät/Device den peerChan (peere-Kanal) auch nicht ;)
D.h. du musst den gewünschten Kanal des Gerätes/Devices nehmen...
...dann sollte es gehen.
Gruß, Joachim
Zitat von: CatWeazle am 19 November 2017, 15:50:45
... mir jetzt auch klar, warum ich die Geräte untereinander nicht mehr peeren kann. also ohne FHEM, Gerät zu Gerät.
Eben.
ZitatGut, dann kann ich aber auch ohne alles zu resetten, alle peers von FHEM aus löschen und neue Verbindungen per SET Befehl zwischen den Gräten etablieren...
Kann man z.B. mit HMinfo die Geräte fragen, welche peers bestehen ?
Zuerst muss sichergestellt sein, dass FHEM alle Register kennt. Dazu müssen die Geräte nach dem Pairen/Anlernen ggf. noch mehrmals (kein Witz!) per "set <gerät> getConfig" zum Herausrücken der Daten überredet werden, normalerweise klappt das von allein, insbesondere wenn das Attribut "autoReadReg" passend gesetzt ist. Dann bietet genau HMInfo den Befehl "peerXref" dafür. Natürlich sind auch bei den HM-Geräten und -kanälen selbst die gepeerten Partner zu sehen (in den Internals unter peerList, fehlt wenn keine peers gesetzt oder bekannt sind). Und bevor das kommt: in den Attributen befindet sich auf "peerIDs", dort steht immer 00000000 und darüber hinaus die HMID der peers (im Gegensatz zum Klarnamen in der peerList), und nein, man kann die Geräte nicht durch Ändern des Attributs peeren.
Zitatund zu guter Letzt, ich lese immer vom peerChan 0, gibt es auch einen peerChan 1 oder 2,3,4 ?
Jawohl. peerChan 0 referenziert immer auf den aktuellen Kanal (plus Folgekanal, wenn "dual"). 1 und darüber beziehen sich auf die Gerätekanäle absolut adressiert, wobei die Zählung wiederum vom peering abhängt - der sechsfach Wandtaster hat die Tasten 1-6 und die Tastenpaare 1-3. "2 xyz dual set" peert die Tasten 3 und 4, "2 xyz single set" die Taste 2. Jetzt verwirrt?
Deswegen immer vom Kanal aus mit 0, dann trifft es garantiert den richtigen ...
Hallo Mike,
ich versteh gar nicht warum Du alles resetten willst, ist in der Regel völlig unnötiger Aufwand.
Ich hatte Dich doch gebeten mal ein list von deinem CUL und eines Diener schon angelernten Geräte, da müssen wir nicht so drumherum reden.
Gruß Otto
Hi Leutz,
@ MadMax:
ZitatHM_56AD6A ist ein Device und kein Channel/Kanal, daher kennt das Gerät/Device den peerChan (peere-Kanal) auch nicht ;)
D.h. du musst den gewünschten Kanal des Gerätes/Devices nehmen...
...dann sollte es gehen.
Wie muss der Set Befehl den aussehen? In meinem Fall ist HM_56AD6A ein HM-Sec-SCo Fensterkontakt optisch.
@Pfriemler, den Fall das man Geräte mehrfach Pairen muss habe ich schon bei der HM-Funksteckdose kennen gelernt. Kann ich mit den anderen HM-Geräten mal durchprobieren.
@Otto, Ja, ich habe auch überlegt, was ich da für ein "list" posten soll, ein Ausschnitt der fhem.cfg, sorry für die Umstände, aber ich habe mit HM noch so meine Probleme.
Auch wenn ich sie schon lange in FHEM eingebunden habe, mit den schon berichteten Problemen.
Auch die Steuerung der HM-Heizungssteuerung über Alexa/HA-Bridge hat mir keine Schwirigkeiten bereitet, aber dieses peeren und pairen treibt mich noch in den Wahn ....
So, jetzt bitte auch für mich die "list" von den Geräten. :D
Gib in der Kommandozeile mal
list HM_56AD6A ein. Die Ausgabe markierst Du mit der Maus und kopierst sie. Dann hier im Eingabefenster einmal auf den Button mit dem # drücken, dann erscheinen zwei Tages mit code und /code. Zwischen diese Tags bitte die Ausgabe einfügen.
Für die anderen dito.
An sich ist der peerChan-Befehl korrekt - die SCo sind einkanalige Geräte. Verstehe auch nicht was da hakt.
Dein FHEM ist aktuell? Typ-Bezeichnung korrekt? Das sehen wir dann alles im Listing, deswegen ist es ja so hilfreich. Der fhem.cfg-Auszug mit der Definition reicht da lange nicht.
Zitatden Fall das man Geräte mehrfach Pairen muss habe ich schon bei der HM-Funksteckdose kennen gelernt.
Ich meinte nicht mehrfach pairen, sondern nach dem Anlernen ggf. mehrfach die Daten einfordern.
Und wie Otto nicht müde wird zu betonen: Lass das Peering wie es ist und lösche nur, was Du aufheben oder verändern willst...
Hallo,
FHEM habe ich heute noch ein Update laufen lassen.
Das list ....
Internals:
DEF 56AD6C
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 3
NAME HM_56AD6C
NOTIFYDEV global
NR 584
NTFY_ORDER 50-HM_56AD6C
STATE MISSING ACK
TYPE CUL_HM
lastMsg No:70 - t:10 s:56AD6C d:000000 06010000
nanoCUL_MSGCNT 3
nanoCUL_RAWMSG A0D70861056AD6C00000006010000::-70:nanoCUL
nanoCUL_RSSI -70
nanoCUL_TIME 2017-11-19 21:19:35
protCmdPend 3 CMDs pending
protLastRcv 2017-11-19 21:19:35
protResnd 3 last_at:2017-11-19 21:19:37
protSnd 3 last_at:2017-11-19 21:19:35
protState CMDs_pending
rssi_at_nanoCUL lst:-70 cnt:3 max:-70 min:-73.5 avg:-71.16
READINGS:
2017-11-19 18:50:01 Activity alive
2017-11-19 16:49:05 D-firmware 1.0
2017-11-19 16:49:05 D-serialNr OEQ0222076
2017-11-19 16:42:38 R-pairCentral set_0xF11234
2017-11-19 16:49:06 aesKeyNbr 00
2017-11-19 16:46:54 alive yes
2017-11-19 16:54:27 battery ok
2017-11-19 16:54:27 contact closed (to broadcast)
2017-11-19 16:46:54 powerOn 2017-11-19 16:46:54
2017-11-19 21:19:35 recentStateType info
2017-11-19 16:46:54 sabotageError off
2017-11-19 18:08:11 state MISSING ACK
2017-11-19 18:16:50 trigDst_broadcast noConfig
2017-11-19 18:16:50 trigger_cnt 21
cmdStack:
++A001F1123456AD6C00040000000000
++A001F1123456AD6C01040000000001
++A001F1123456AD6C0103
helper:
HM_CMDNR 113
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56AD6C,02,00,00
nextSend 1511122775.17421
prefIO
rxt 2
vccu
p:
56AD6C
00
00
00
mRssi:
mNo 70
io:
nanoCUL -68
prt:
bErr 0
sProc 2
wuReSent 4
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -71.1666666666667
cnt 3
lst -70
max -70
min -73.5
tmpl:
Attributes:
IODev nanoCUL
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
room CUL_HM,Wohnzimmer
serialNr OEQ0222076
Knapp daneben, das sind Zitate. Code Tags findest Du über dem :-X Smily, die # Taste. Kannst Du auch nachträglich ändern.
Mach jetzt noch bitte ein list nanoCUL
Der HM-SEC-SCo ist nicht gepairt, zumindest nicht fertig. Du musst zur Datenübertragung den Configtaster drücken ohne den Sensor auszulösen!!!
Gruß Otto
Hallo Otto,
hier ist es ......
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1234
DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
FD 17
FHTID 1234
NAME nanoCUL
NR 519
NR_CMD_LAST_H 5
PARTIAL
RAWMSG A0F2C861051B1F60000000A80CD8C0040F3
RSSI -80.5
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString X21
Ar
nanoCUL_MSGCNT 343
nanoCUL_TIME 2017-11-19 22:15:40
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-02-25 18:19:03 ccconf freq:0.000MHz bWidth:58KHz rAmpl:42dB sens:8dB
2017-11-19 18:50:00 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
2017-02-25 18:18:46 credit10ms 598
2017-02-25 18:19:34 fhtbuf AE
2017-03-01 18:10:05 raw isF00F00FFFFF0
2017-11-19 22:15:40 state Initialized
XMIT_TIME:
1511122775.22298
1511123176.64028
1511125111.0811
1511125111.35412
1511125111.54651
helper:
51B1F6:
QUEUE:
56AD6C:
QUEUE:
56AD88:
QUEUE:
Attributes:
rfmode HomeMatic
Wenn man zu schnell ist .... sorry ...
ich hatte doch Fragen!
ZitatDer HM-SEC-SCo ist nicht gepairt, zumindest nicht fertig.
Woran erkennt man das?
Dann:
ZitatDu musst zur Datenübertragung den Configtaster drücken ohne den Sensor auszulösen!!!
Kann das aus versehen passieren? denn weder Fenster noch Sensor bewegen sich wenn ich den Pairknopf am Fesnstersensor drücke.
Oder ist etwas anderes gemeint ?
ZitatR-pairCentral set_0xF11234
Hier darf kein set_ davor stehen
Es muss so aussehen
R-pairCentral 0xF11234 Der Fenstersensor überträgt auch Daten wenn man ihn auslöst (Fenster aufmacht, oder mit der Hand die Lichschranke auslöst) , aber diese werden aus Sicherheitsgründen nicht für Konfigurationsänderungen verwendet.
Du erkennst die Datenübertragung am Blinkrythmus. Eventuell brauchst Du nur noch einmal ein getConfig abzusetzen und dann 1 bis zweimal (mit Ruhe und mit Pause) den configtaster drücken.
Diese Verhalten ist nicht bei allen Sensoren so. Bei Bewegungsmeldern werden die Konfigurationsdaten auch übertragen wenn man ihn auslöst.
Diese Zahl F11234 ist die HMID Deiner Zentrale. Eine Eigenheit des CUL, er nimmt den Hauscode (1234) aus Deiner DEF und macht ihn mit F1 davor zur HMID. Normalerweise muss man ein attribute setzen.
Gruß Otto
Hallo Otto,
nach getConfig hat sich das listing geändert.
Internals:
DEF 56AD6C
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 17
NAME HM_56AD6C
NOTIFYDEV global
NR 584
NTFY_ORDER 50-HM_56AD6C
STATE closed
TYPE CUL_HM
lastMsg No:CC - t:41 s:56AD6C d:000000 011D00
nanoCUL_MSGCNT 17
nanoCUL_RAWMSG A0CCC844156AD6C000000011D00::-70.5:nanoCUL
nanoCUL_RSSI -70.5
nanoCUL_TIME 2017-11-19 23:19:12
protCmdDel 4
protCmdPend 10 CMDs_pending
protLastRcv 2017-11-19 23:19:12
protResnd 3 last_at:2017-11-19 21:19:37
protResndFail 1 last_at:2017-11-19 22:17:59
protSnd 16 last_at:2017-11-19 23:16:50
protState CMDs_pending
rssi_at_nanoCUL avg:-69.11 max:-65.5 min:-73.5 lst:-70.5 cnt:17
READINGS:
2017-11-19 23:16:49 Activity alive
2017-11-19 23:16:49 D-firmware 1.0
2017-11-19 23:16:49 D-serialNr OEQ0222076
2017-11-19 23:16:49 PairedTo 0x000000
2017-11-19 23:17:55 R-HM_587E68_WindowRec-expectAES set_off
2017-11-19 23:17:55 R-HM_587E68_WindowRec-peerNeedsBurst set_on
2017-11-19 23:16:28 R-cyclicInfoMsg on
2017-11-19 23:16:28 R-eventDlyTime 0 s
2017-11-19 23:16:28 R-pairCentral 0x000000
2017-11-19 23:16:28 R-sabotageMsg on
2017-11-19 23:16:28 R-sign on
2017-11-19 23:16:49 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
2017-11-19 23:16:49 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2017-11-19 16:49:06 aesKeyNbr 00
2017-11-19 16:46:54 alive yes
2017-11-19 23:19:12 battery ok
2017-11-19 23:19:12 contact closed (to broadcast)
2017-11-19 16:46:54 powerOn 2017-11-19 16:46:54
2017-11-19 23:13:12 recentStateType info
2017-11-19 16:46:54 sabotageError off
2017-11-19 23:19:12 state closed
2017-11-19 18:16:50 trigDst_broadcast noConfig
2017-11-19 23:19:12 trigger_cnt 29
cmdStack:
++A001F1123456AD6C0101587E680300
++A001F1123456AD6C0105587E680304
++A001F1123456AD6C01080101
++A001F1123456AD6C0106
++A001F1123456AD6C0101587E680300
++A001F1123456AD6C0105587E680304
++A001F1123456AD6C01080101
++A001F1123456AD6C0106
++A001F1123456AD6C0102587E680300
++A001F1123456AD6C0102587E680300
helper:
HM_CMDNR 204
cSnd 01F1123456AD6C01040000000001,01F1123456AD6C0103
mId 00C7
peerIDsRaw ,00000000
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56AD6C,02,00,00
nextSend 1511129952.71081
prefIO
rxt 2
vccu
p:
56AD6C
00
00
00
mRssi:
mNo CC
io:
nanoCUL -68.5
prt:
bErr 0
sProc 2
rspWait:
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -69.1176470588235
cnt 17
lst -70.5
max -65.5
min -73.5
shadowReg:
RegL_04.HM_587E68_WindowRec 01:01
tmpl:
Attributes:
IODev nanoCUL
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,
room CUL_HM,Wohnzimmer
serialNr OEQ0222076
subType threeStateSensor
jetzt steht da: R-pairCentral 0x000000
hmmm ist scheinbar auch nicht richtig, wenn es doch 0xF11234 heißen sollte ?!?!?
mir fehlt leider komplett das Verständnis für die meisten dieser Parameter :-(
Grüße
Mike
Hi leutz,
nur um die liste fürs Wohnzimmer komplett zu machen.
Wandthermostat:
Internals:
DEF 587E68
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 253
NAME HM_587E68
NOTIFYDEV global
NR 562
NTFY_ORDER 50-HM_587E68
STATE Nack
TYPE CUL_HM
channel_01 HM_587E68_Weather
channel_02 HM_587E68_Climate
channel_03 HM_587E68_WindowRec
channel_06 HM_587E68_remote
channel_07 HM_587E68_SwitchTr
lastMsg No:03 - t:70 s:587E68 d:000000 00E130
nanoCUL_MSGCNT 253
nanoCUL_RAWMSG A0C038470587E6800000000E130::-47:nanoCUL
nanoCUL_RSSI -47
nanoCUL_TIME 2017-11-19 23:40:13
protCmdDel 1
protLastRcv 2017-11-19 23:40:13
protNack 1 last_at:2017-11-19 23:23:49
protSnd 4 last_at:2017-11-19 23:23:48
protState CMDs_done_Errors:1
rssi_at_nanoCUL avg:-47.52 lst:-47 cnt:253 min:-49.5 max:-46.5
READINGS:
2017-11-19 18:50:01 Activity alive
2017-11-19 23:23:49 CommandAccepted no
2017-10-07 12:16:57 D-firmware 1.3
2017-10-07 12:16:57 D-serialNr OEQ0298561
2017-04-27 17:59:50 PairedTo 0xF11234
2017-04-27 17:58:26 R-burstRx on
2017-04-27 17:58:26 R-cyclicInfoMsg on
2017-04-27 17:58:26 R-cyclicInfoMsgDis 0
2017-04-27 17:58:26 R-pairCentral 0xF11234
2017-04-27 17:59:50 RegL_00. 01:01 02:01 09:01 0A:F1 0B:12 0C:34 0F:00 11:00 12:16 16:01 18:00 19:00 1A:00 00:00
2017-11-19 17:06:06 RegL_07.
2017-11-19 23:31:06 battery ok
2017-11-19 23:31:06 batteryLevel 2.8
2017-11-19 23:31:06 desired-temp 22.0
2017-11-19 23:31:06 measured-temp 22.5
2017-09-08 18:00:51 powerOn 2017-09-08 18:00:51
2017-09-08 18:00:51 recentStateType info
2017-11-19 23:23:49 state Nack
2017-11-19 02:06:36 time-request -
helper:
HM_CMDNR 3
cSnd 01F11234587E68030256AD6C0101,01F11234587E68030256AD6C0101
mId 00AD
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +587E68,00,00,00
nextSend 1511131213.34536
prefIO
rxt 0
vccu
p:
587E68
00
00
00
mRssi:
mNo 03
io:
nanoCUL -45
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf 02,03
qReqStat
role:
dev 1
rssi:
at_nanoCUL:
avg -47.5217391304348
cnt 253
lst -47
max -46.5
min -49.5
shRegW:
07 02
tmpl:
Attributes:
IODev nanoCUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
model HM-TC-IT-WM-W-EU
msgRepeat 1
room CUL_HM,Wohnzimmer
serialNr OEQ0298561
subType thermostat
webCmd getConfig:clear msgEvents
Heizköperthermostat:
Internals:
DEF 51A418
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 112
NAME HM_51A418
NOTIFYDEV global
NR 531
NTFY_ORDER 50-HM_51A418
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_51A418_Weather
channel_02 HM_51A418_Climate
channel_03 HM_51A418_WindowRec
channel_04 HM_51A418_Clima
channel_05 HM_51A418_ClimaTeam
channel_06 HM_51A418_remote
lastMsg No:C0 - t:10 s:51A418 d:000000 0AB0E10E0040
nanoCUL_MSGCNT 112
nanoCUL_RAWMSG A0FC0861051A4180000000AB0E10E0040::-53.5:nanoCUL
nanoCUL_RSSI -53.5
nanoCUL_TIME 2017-11-19 23:41:09
protLastRcv 2017-11-19 23:41:09
rssi_at_nanoCUL avg:-53.66 min:-55 max:-52.5 lst:-53.5 cnt:112
READINGS:
2017-11-19 18:50:01 Activity alive
2017-11-19 18:47:30 CommandAccepted yes
2017-05-11 16:30:53 D-firmware 1.4
2017-05-11 16:30:53 D-serialNr NEQ1491261
2017-09-08 18:01:31 PairedTo 0xF11234
2017-04-27 17:49:07 R-backOnTime 10 s
2017-04-27 17:49:07 R-burstRx on
2017-04-27 17:49:07 R-cyclicInfoMsg on
2017-04-27 17:49:07 R-cyclicInfoMsgDis 0
2017-04-27 17:49:07 R-pairCentral 0xF11234
2017-09-08 18:01:31 RegL_00. 01:01 02:01 09:01 0A:F1 0B:12 0C:34 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2017-11-19 18:49:47 RegL_07.
2017-11-19 23:41:09 actuator 0
2017-11-19 23:41:09 battery ok
2017-11-19 23:41:09 batteryLevel 2.9
2017-11-15 11:55:02 controlMode manual
2017-11-19 23:41:09 desired-temp 22.0
2017-11-19 23:41:09 measured-temp 22.5
2017-11-19 23:41:09 motorErr ok
2017-09-08 17:58:27 powerOn 2017-09-08 17:58:27
2017-09-08 17:58:27 recentStateType info
2017-11-19 18:47:36 state CMDs_done
2017-11-18 19:39:12 time-request -
helper:
HM_CMDNR 192
mId 0095
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +51A418,00,00,00
nextSend 1511131269.01363
prefIO
rxt 2
vccu
p:
51A418
00
00
00
mRssi:
mNo C0
io:
nanoCUL -51.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_nanoCUL:
avg -53.6696428571429
cnt 112
lst -53.5
max -52.5
min -55
shRegW:
07 04
tmpl:
Attributes:
IODev nanoCUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr NEQ1491261
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
und vielen Dank für eure Geduld mit mir :-)
Hallo Mike,
Du musst beim HM_56AD6C nochmal die Datenübertragung anschupsen - configtaste drücken und warten.
Die hier protCmdPend 10 CMDs_pending müssen abgearbeitet werden.
Das wird schon.
Gruß Otto
Hallo Otto,
über Nacht hat sich das Listing ohne mein Zutun verändert.
Internals:
DEF 56AD6C
IODev nanoCUL
NAME HM_56AD6C
NOTIFYDEV global
NR 584
STATE closed
TYPE CUL_HM
READINGS:
2017-11-20 17:52:03 Activity alive
2017-11-19 23:16:49 D-firmware 1.0
2017-11-19 23:16:49 D-serialNr OEQ0222076
2017-11-19 23:16:49 PairedTo 0x000000
2017-11-19 23:17:55 R-HM_587E68_WindowRec-expectAES set_off
2017-11-19 23:17:55 R-HM_587E68_WindowRec-peerNeedsBurst set_on
2017-11-19 23:16:28 R-cyclicInfoMsg on
2017-11-19 23:16:28 R-eventDlyTime 0 s
2017-11-19 23:16:28 R-pairCentral 0x000000
2017-11-19 23:16:28 R-sabotageMsg on
2017-11-19 23:16:28 R-sign on
2017-11-19 16:49:06 aesKeyNbr 00
2017-11-20 17:41:49 alive yes
2017-11-20 17:41:49 battery ok
2017-11-20 17:41:49 contact closed (to broadcast)
2017-11-19 16:46:54 powerOn 2017-11-19 16:46:54
2017-11-20 17:41:49 recentStateType info
2017-11-20 17:41:49 sabotageError off
2017-11-20 17:41:49 state closed
2017-11-19 18:16:50 trigDst_broadcast noConfig
2017-11-20 17:11:44 trigger_cnt 35
helper:
HM_CMDNR 177
mId 00C7
rxType 28
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56AD6C,00,00,00
prefIO
rxt 2
vccu
p:
56AD6C
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
chn 1
dev 1
tmpl:
Attributes:
IODev nanoCUL
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
room CUL_HM,Wohnzimmer
serialNr OEQ0222076
Aber Pair zu 0x000000 nicht zu 0xF11234 wie die Anderen.
Grüße
Mike
Ich heiß zwar nicht Otto, aber...
Zitat von: CatWeazle am 20 November 2017, 18:00:36
über Nacht hat sich das Listing ohne mein Zutun verändert.
...
Aber Pair zu 0x000000 nicht zu 0xF11234 wie die Anderen.
1. glaube ich kaum. Höchstens der Zustand des Fensterkontaktes. Dadurch sieht auch ein erneutes Listing anders aus. Aber ein vorhandenes kann sich nicht mehr ändern. ;D ;D ;D ;D
2. Fensterkontakt ist ungepairt. Also nachholen: Befehl in FHEM absetzen und zeitnah (!) 's Gnöbbsche am Fensterkontakt drücken. Dann muss der hektisch gelb blinken und am Ende kurz grün leuchten.
Hallo,
ZitatBefehl in FHEM absetzen und zeitnah (!) 's Gnöbbsche am Fensterkontakt drücken. Dann muss der hektisch gelb blinken und am Ende kurz grün leuchten.
Befehl: set nanoCUL hmPairForSec 30, LED wird nach dem Gnöbbsche am Fensterkontakt drücken kurz Rot oder orange und ist dann sofort grün und aus.
Ich habe diesen Fensterkontakt wiederholt resettet und versucht neu zu Pairen, immer das gleiche, kurz orange dann grün und aus.
Ich versuche es weiter, auch set / getConfig hat nicht geholfen .....
Hi Leutz,
ich glaube ich habe da etwas gefunden.
Kann es sein, das sich der Fensterschalter (HM_56AD6C) nicht richtig mit dem NanoCul pairen lässt weil noch ein altes Peering mit dem Heizkörperthermostat (HM_51A418) besteht?
Internals:
DEF 51A41803
NAME HM_51A418_WindowRec
NOTIFYDEV global
NR 534
STATE last:HM_56AD6C:0
TYPE CUL_HM
chanNo 03
device HM_51A418
peerList HM_56AD6C,
READINGS:
2017-04-27 17:49:09 R-sign off
2017-11-20 21:34:41 RegL_01. 08:00 00:00
2017-11-20 21:34:46 RegL_03.HM_56AD6C_chn-01 04:32 00:00
2017-11-20 21:34:46 RegL_07.HM_56AD6C_chn-01 05:18 00:00
2017-11-20 21:34:41 peerList HM_56AD6C,
2017-11-20 21:34:41 state unknown
2017-10-07 11:47:08 trigLast HM_56AD6C:0
2017-10-07 11:47:08 trig_HM_56AD6C 0_4
helper:
peerIDsRaw ,56AD6C01,00000000
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,56AD6C01,
stateFormat last:trigLast
wie war noch gleich der Befehl, dem Heizkörperthermostat den Fensterschalter vergessen zu lassen, also unpeeren
Grüße
mike
Nö. Peerings stören beim Pairen nicht.
Ja ich weiß auch nicht mehr, rssi ist ok (-70). Würde zum Entpeeren
set HM_56AD6C peerChan 0 HM_51A418_WindowRec single unset actor
versuchen (überträgt nur an den Partner, also WindowsRec). Aber wie gesagt eigentlich unnötig, wenn das ohnehin wieder geplant ist.
Noch jemand ne Idee warum es wiederholt nicht klappt? Außer dass vll. der Fensterkontakt defekt ist (nur noch sendet, nicht mehr empfängt)?
okay, wenn ein bestehendes peer beim pairen nicht stört, dann mach es keinen Sinn es aufzulösen, zumal es später auch wieder etabliert werden soll.
Nach unzähligen pair-Versuchen, habe ich jetzt mal wieder:
2017-11-20 22:39:27 R-pairCentral set_0xF11234
aber mit set_ ist es ja wohl nutzlos.
grüße
mike
Hii,
die Fensterkontakte sind zickig. Und Du hast einen CUL das macht die Sache nicht einfacher.
Ich denke der funktioniert, sonst würde er nicht so weit kommen.
Du darfst beim Knopf drücken nicht den Sensor auslösen! Also Fenster bewegen oder mit der Hand in die Lichtschranke kommen.
Du kannst auch ein set HM_56AD6C clear msgEvents absetzen und dann ein getConfig. CMDs abarbeiten, Ruhe bewahren, Zeit lassen.
Du kannst auch ein set HM_56AD6C clear all machen und das Pairing nochmal versuchen.
Gruß Otto
Hi Leutz,
Dieser Fensterkontakt kostet echt Nerven.
Ich habe mal ein List vom Schlafzimmer-Fensterkontakt gemacht, der hat im Pair auch set_0xF11234 stehen.
Allerdings ist er mit dem Schlafzimmerthermostat gepeert und funktioniert.
Internals:
DEF 56AD88
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 2
NAME HM_56AD88
NOTIFYDEV global
NR 590
STATE MISSING ACK
TYPE CUL_HM
lastMsg No:50 - t:10 s:56AD88 d:000000 06010000
nanoCUL_MSGCNT 2
nanoCUL_RAWMSG A0D50861056AD8800000006010000::-84:nanoCUL
nanoCUL_RSSI -84
nanoCUL_TIME 2017-11-20 22:45:51
peerList HM_51B1F6_WindowRec,
protCmdPend 3 CMDs pending
protLastRcv 2017-11-20 22:45:51
protResnd 2 last_at:2017-11-20 22:45:54
protSnd 2 last_at:2017-11-20 22:45:51
protState CMDs_pending
rssi_at_nanoCUL max:-82 cnt:2 min:-84 lst:-84 avg:-83
READINGS:
2017-11-20 21:24:03 Activity alive
2017-04-27 19:56:20 CommandAccepted yes
2017-05-11 16:27:04 D-firmware 1.0
2017-05-11 16:27:04 D-serialNr OEQ0222104
2017-04-27 18:33:09 R-pairCentral set_0xF11234
2017-04-27 19:58:39 aesKeyNbr 00
2017-05-11 19:35:04 alive yes
2017-05-11 19:35:04 battery ok
2017-05-11 19:35:04 contact closed (to broadcast)
2017-11-20 21:24:03 peerList HM_51B1F6_WindowRec,
2017-11-18 00:55:48 powerOn 2017-11-18 00:55:47
2017-11-20 22:45:51 recentStateType info
2017-04-27 19:56:19 sabotageAttackId_ErrIoId_51B1F6 cnt:3
2017-04-27 19:56:19 sabotageAttack_ErrIoAttack cnt 3
2017-05-11 19:35:04 sabotageError off
2017-11-19 22:19:34 state MISSING ACK
2017-11-20 11:55:02 trigger_cnt 28
cmdStack:
++A001F1123456AD8800040000000000
++A001F1123456AD8801040000000001
++A001F1123456AD880103
helper:
HM_CMDNR 81
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +56AD88,02,00,00
nextSend 1511214351.65093
prefIO
rxt 2
vccu
p:
56AD88
00
00
00
mRssi:
mNo 50
io:
nanoCUL -82
prt:
bErr 0
sProc 2
wuReSent 3
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_nanoCUL:
avg -83
cnt 2
lst -84
max -82
min -84
tmpl:
Attributes:
IODev nanoCUL
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SCo
peerIDs 00000000,51B1F603,
room CUL_HM,Schlafzimmer
serialNr OEQ0222104@Otto:
ZitatUnd Du hast einen CUL das macht die Sache nicht einfacher
würde ein ELV Homematic Funkmodul für Raspberry Pi über ein USB2RS232 helfen?
Grüße
Mike
@CatWeazle
hast du mal ins fhem.log geschaut, steht da etwas von libcrypt-rijndael-perl?
Zitat von: fhem-hm-knecht am 20 November 2017, 23:06:27
hast du mal ins fhem.log geschaut, steht da etwas von libcrypt-rijndael-perl?
*handvordiestirnschlagend* ... dammich, ich schließe mich dem Orakel an ...?
und sonst: JEDE original HM-Hardware ist besser für HM... (wegduck)
Zitathast du mal ins fhem.log geschaut, steht da etwas von libcrypt-rijndael-perl?
Hab eben nachgesehen, libcrypt-rijndael-perl oder auch Teile davon (ausser perl) stehen nicht in der fhem.log
ist schon witzig, zwei Heizkörperthermostate und zwei Wandthermostate ohne Probleme gepairt, nur die Fensterkontakte bocken :-(
Vielleicht sollte ich die 20eur in die Hand nehmen und das ELV Modul bestellen, kommt ja portofrei :-)
nur die Fensterkontakte bocken , --> die haben AES von Haus aus an.
und dein Cul kann kein AES von Haus aus.
tipp mal version ein und poste,
Version:
Latest Revision: 15451
File Rev Last Change
fhem.pl 15377 2017-11-01 16:59:23Z rudolfkoenig
90_at.pm 14995 2017-09-03 14:23:14Z rudolfkoenig
98_autocreate.pm 15377 2017-11-01 16:59:23Z rudolfkoenig
00_CUL.pm 15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm 15422 2017-11-11 16:43:17Z martinp876
10_CUL_IR.pm 3580 2013-08-02 16:17:38Z betateilchen
14_CUL_TCM97001.pm 15367 2017-10-31 17:44:02Z bjoernh
14_CUL_TX.pm 14784 2017-07-25 15:06:43Z rudolfkoenig
98_DOIF.pm 14790 2017-07-26 10:27:41Z Damian
70_ENIGMA2.pm 14985 2017-09-01 11:18:48Z loredo
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm 15328 2017-10-27 10:51:17Z rudolfkoenig
92_FileLog.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
No Id found for 00_GenShellSwitch.pm
No Id found for 58_GPIO4.pm
98_HMinfo.pm 14608 2017-07-01 04:53:04Z martinp876
10_IT.pm 14852 2017-08-06 08:48:24Z bjoernh
91_notify.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
41_OREGON.pm 34476 2016-12-04 13:00:00Z dev
70_PHTV.pm 14400 2017-05-28 11:10:33Z loredo
73_PRESENCE.pm 15302 2017-10-22 11:32:19Z markusbloch
95_remotecontrol.pm 10724 2016-02-04 18:17:33Z ulimaass
51_RPI_GPIO.pm 15350 2017-10-29 21:58:26Z klausw
14_SD_RSL.pm 7779 2017-11-14 18:00:00Z v3.3.1-dev
14_SD_WS.pm 39 2017-09-08 22:00:00Z v3.3-dev
14_SD_WS07.pm 9346 2017-04-16 16:00:00Z v3.3.1-dev
00_SIGNALduino.pm 10488 2017-11-19 11:00:00Z v3.3.1-dev
# $Id: 90_SIGNALduino_un.pm 15479 2016-01-28 20:00:00 dev-r32 $
99_SUNRISE_EL.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_SVG.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
50_TelegramBot.pm 15421 2017-11-11 16:02:47Z viegener
98_telnet.pm 15006 2017-09-05 09:37:33Z rudolfkoenig
99_Utils.pm 13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm 12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
Blocking.pm 15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
DevIo.pm 14933 2017-08-20 14:21:58Z rudolfkoenig
HMConfig.pm 15337 2017-10-29 06:43:02Z martinp876
HttpUtils.pm 15434 2017-11-15 13:21:28Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm 14862 2017-08-07 15:16:03Z rudolfkoenig
YahooWeatherAPI.pm 12465 2016-10-29 09:01:31Z borisneubert
fhemweb.js 15228 2017-10-10 17:34:56Z rudolfkoenig
Grüße
Mike
Zitat von: mgernoth am 19 November 2017, 21:52:29
Hallo,
Ja, anscheinend führt die aktuelle assignIO-Logik (wird noch an anderen Stellen aufgerufen) dazu, dass der Fhem-Kern die Verzögerung auslöst.
Hier ist die aktuelle CUL_HM.pm mit der alten assignIO-Logik, damit sollten die Probleme erstmal behoben sein:
https://rmdir.de/~michael/10_CUL_HM.pm
Viele Grüße
Michael
nimm mal die vom mgernoth, deine ist zu neu
Hi,
ich habe mal in meinem in #2 verlinkten Wiki Artikel noch den Hinweis zu AES eingebaut.
Und ja: Wenn Du Dir was gutes tun willst hol Dir das eq3 Modul bei elv!
Gruß Otto
Hi Leutz,
okay, nochmal zu AES,
Zitatund dein Cul kann kein AES von Haus aus.
Bedeutet das, man kann dem CUL AES beibringen? pure Neugier ?!?!?! denn ....
Ich bestell mit das eq3 Modul bei ELV.
Damit ich nichts falsches bestelle, hier nochmal die Frage nach dem Richtigen Modul.
Dieses Modul:
ELV Homematic Komplettbausatz Funkmodul für Raspberry Pi Artikel-Nr.: 68-14 21 41
beste Grüße
Mike
Unser Wiki ist gar nicht so schlecht.
Beispielsweise findet man in diesem Abschnitt zu AES Encryption (https://wiki.fhem.de/wiki/AES_Encryption#I.2FO-Device_.E2.86.90.E2.86.92_Ger.C3.A4t):
ZitatFür alle CUL-kompatiblen Geräte muss das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl) installiert sein
Ja, das Modul ist richtig. Kann man sogar bei real,- kaufen. Für 3 Euro mehr. Aha. ;D
P.S: Ich verstehe die Sig noch immer nicht.
Gut, erst mal Danke.
okay, die Sig könnte anders lauten, aber als Biker ... ja doch, das Wetter könnte besser sein 8)
Auf der anderen Seite, im Sept. ist mein neuer Golf Performance geliefert worden, der macht auch in weniger gutem Wetter Spass ;D
Aber bei besserem Wetter mehr Spass, also passt die Sig auch da.
OT:
"Wir Zeit für besser Wetter!" ist kein richtiger Satz. Ich vermute "Wird Zeit für besser Wetter!" ist gemeint. Zusätzlich sind auch die Sternchen nicht richtig zum Block geformt.
Also: Was ist richtig? 8)
Danke, wat peinlich ::)
Hi Leutz,
wenn der HM-MOD-RPI-PCB geiefert wird, werde ich es über einen USB_to_RS232 Adapteran den Raspi anschließen, die GPIOs halte ich mir frei.
Entweder über die ID
define myHmUART HMUARTLGW /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
oder über den USB_Port
define myHmUART HMUARTLGW /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0
Damit ich kompatibel bleibe übernehme ich meine jetzige HMID
attr myHmUART hmId 0xF11234
passt das so?
Ach ja, um die AES Encryption brauche ich mich ja bei diesem Modul nicht weiter kümmern, gelle, oder ?
Beste Grüße
Mike
Hallo Mike,
die GPIO hältst Du frei für die Frühjahrsausfahrt? ;D
Wenn Du neue Rauchmelder hast (SD-2) brauchst Du auch das Perl-Modul Crypt::Rijndael (Debian: libcrypt-rijndael-perl). Warum steht im Wiki :D
Gruß Otto
1. Über USB geht auch, Anleitungen gibt es ja hier diverse. Wenn die serial-ID die des USB-RS232-Adapters ist, immer diese Variante bevorzugen.
2. hmId ohne 0x, also nur F11234
3. AES mit Standardschlüssel sollte sofort funktionieren. Kann aber nicht beschwören, ob ich nicht doch die crypt-lib mal installiert habe.
In jedem Fall wirst Du auch mit kritischen Devices viel leichter eine stabile Kommunikation haben.
Wenn Du jetzt noch eine VCCU dazu definierst (mit der gleichen hmId), kannst du CUL und HMUART parallel nutzen.
edit: Otto hat natürlich recht bzgl. SD-2 - habe ich aber nicht (kommt mir auch nicht ins Haus, aber das ist eine andere Geschichte ...)
Hi Leutz,
okay, meine Rauchmelder sind nicht von HM, also ist das AES Problem für mich erledigt, das ist gut :)
Einbinden über die serial-ID ist auch mein Favorit.
Wenn Du jetzt noch eine VCCU dazu definierst (mit der gleichen hmId), kannst du CUL und HMUART parallel nutzen.
Führt zu welchem Vorteil ? ich steuere mit dem CUL nur meine HM-Geräte, habe noch einen SignalDuino laufen, für Funksteckdosen, Wetterstation, Funksender ....
Grüße
Mike
Schaden tut Crypt::Rijndael auf keinen Fall, kostet auch nicht extra ;D
Und AES ist kein Problem ;D
Und mit der VCCU lässt es sich einfach schwenken oder "migrieren" http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU
Gruß Otto
Hi Leutz,
ja, der HM-OCCU-PCB ist da, und schon zusammen gelötet.
Jetzt mein Plan:
1. HM-OCCU-PCB über einen CP2102 an einen freien USB am Raspi angeschlossen
2. define myHmUART HMUARTLGW /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
3. attr myHmUART hmId F11234
Mein CUL mit gleicher hmid ist auch noch angeschlossen.
Aber CUL und HM-OCCU-PCB stören sich nicht.
Optional kann man VCCU dazu definieren, muss ich mir in der Wiki ansehen, weiß noch nicht wie.
Da die HM-Komponenten, bis auf die beiden Fensterkontakte, schon mit der CUL-Zentrale F11234 gepaart sind, sollte der HM-OCCU-PCB mit gleicher hmid doch auch als Zentrale erkannt werden.
Habe ich das so richtig verstanden?
Das Paaring mit den widerspenstigen optischen Fensterkontakten sollte mit dem HM-OCCU-PCB funktionieren, da wir beim CUL ja ein AES-Poblem erkannt haben.
Soweit so gut :)
Eure Meinung?
Beste Grüße
Mike
soweit so gut
Ach ja, nachdem .... sudo apt-get install libcrypt-rijndael-perl .... reebot ....
wurde der widerspenstige optische Fensterkontakt auch gleich im ersten Versuch sauber mit meinem alten CUL gepairt.
Dann kann es mit dem HM-OCCU-PCB nur noch besser werden.
Fürs Erste, vielen Dank für eure Hilfe.
Beste Grüße und ein schönes Wochenende
Mike
libcrypt-rijndael-perl
zum Glück hatte ich nicht gefragt ;)
;)
Hi Leutz,
ja gut das niemand gefragt hatte ;)
Jetzt, da jetzt mein alter Eigenbau-CUL AES spricht, funktioniert auf einmal alles, das sag ich sie :)
Nun habe ich zwar den schönen neuen HM-OCCU-PCB einsatzbereit hier liegen, aber da es mit dem CUL auf einmal so gut löppt ......
Dennoch gibt es Probleme!
HM-Info gibt auf Check folgende Ungereimtheiten aus:
trigger sent to unpeered device
triggerUnpeered: HM_56AD6C:F11234
triggerUnpeered: HM_56AD88:F11234
trigger sent to undefined device
triggerUndefined: HM_56AD6C:F11234
triggerUndefined: HM_56AD88:F11234
PairedTo mismatch to IODev
HM_51A418 paired:0xF11234 IO attr: -.
HM_51B1F6 paired:0xF11234 IO attr: -.
HM_52DBE6 paired:0xF11234 IO attr: -.
HM_56AD6C paired:0xF11234 IO attr: -.
HM_56AD88 paired:0xF11234 IO attr: -.
HM_587E68 paired:0xF11234 IO attr: -.
HM_587E6A paired:0xF11234 IO attr: -.
Okay, die ersten beiden sind die optischen Fensterkontakte, zu dem threeStateSensor habe ich gefunden, dass sie an die Zentrale senden, das soll man ignorieren.
Der PairedTo mismatch to IODev Block ist mir dann doch ein Rätsel, da aber alles einwandfrei funktioniert, stört der mich auch nicht wirklich. Kann man den auch ignorieren?
Beste Grüße
Mike
HM_51A418 paired:0xF11234 IO attr: -.
dann zeige doch ein list HM_51A418
wir sehen nicht was du siehst.
Edit:
CUL auf einmal so gut löppt ......
ich lasse dich mal in deinem positiven Glauben :) ,
Büddeschön :)
Internals:
DEF 51A418
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 70
NAME HM_51A418
NOTIFYDEV global
NR 530
NTFY_ORDER 50-HM_51A418
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_51A418_Weather
channel_02 HM_51A418_Climate
channel_03 HM_51A418_WindowRec
channel_04 HM_51A418_Clima
channel_05 HM_51A418_ClimaTeam
channel_06 HM_51A418_remote
lastMsg No:73 - t:10 s:51A418 d:000000 0AA8D80E0040
nanoCUL_MSGCNT 70
nanoCUL_RAWMSG A0F73861051A4180000000AA8D80E0040::-66:nanoCUL
nanoCUL_RSSI -66
nanoCUL_TIME 2017-11-27 19:39:54
protCmdDel 2
protLastRcv 2017-11-27 19:39:54
protResnd 8 last_at:2017-11-27 19:19:27
protResndFail 1 last_at:2017-11-27 18:48:34
protSnd 48 last_at:2017-11-27 19:21:38
protState CMDs_done
rssi_at_nanoCUL avg:-69.37 lst:-66 max:-63 min:-88 cnt:70
READINGS:
2017-11-27 18:34:11 Activity alive
2017-11-27 19:21:29 CommandAccepted yes
2017-11-26 14:58:45 D-firmware 1.4
2017-11-26 14:58:45 D-serialNr NEQ1491261
2017-11-27 19:21:30 PairedTo 0xF11234
2017-04-27 17:49:07 R-backOnTime 10 s
2017-04-27 17:49:07 R-burstRx on
2017-04-27 17:49:07 R-cyclicInfoMsg on
2017-04-27 17:49:07 R-cyclicInfoMsgDis 0
2017-04-27 17:49:07 R-pairCentral 0xF11234
2017-11-27 19:21:29 RegL_00. 01:01 02:01 09:01 0A:F1 0B:12 0C:34 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2017-11-27 19:39:54 actuator 0
2017-11-27 19:39:54 battery ok
2017-11-27 19:39:54 batteryLevel 2.9
2017-11-27 11:27:38 controlMode manual
2017-11-27 19:39:54 desired-temp 21.0
2017-11-27 19:39:54 measured-temp 21.6
2017-11-27 19:39:54 motorErr ok
2017-11-20 21:01:57 powerOn 2017-11-20 21:01:57
2017-11-20 21:01:57 recentStateType info
2017-11-27 19:21:39 state CMDs_done
2017-11-27 12:19:19 time-request -
RegL_07.:
VAL
helper:
HM_CMDNR 115
cSnd 01F1123451A418030456AD6C0103,01F1123451A418030456AD6C0107
mId 0095
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +51A418,00,00,00
nextSend 1511807994.72367
prefIO
rxt 2
vccu
p:
51A418
00
00
00
mRssi:
mNo 73
io:
nanoCUL -64
prt:
awake 0
bErr 0
brstWu 1
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_nanoCUL:
avg -69.3785714285714
cnt 70
lst -66
max -63
min -88
shRegW:
07 04
shadowReg:
tmpl:
Attributes:
IODev nanoCUL
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr NEQ1491261
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Grüße
Mike
Zitat von: CatWeazle am 19 November 2017, 12:41:18
Ich glaube wenn ich das sauber ans Laufen gebracht habe, werde ich eine Step by Step Anleitung für die Nachwelt verfassen :-)
Läuft es jetzt bei dir und vor allem hast du die Step by Step Anleitung fertig?
Ich stehe aktuell vor einem ähnlichen Problem, dass ich mehrere HM-Fensterkontakte, Thermostate und Wandthermostate pairen und peeren möchte.
Als ich noch keine Wandthermostate hatte hab ich zunächst die Heizkörper-Thermostate der Reihe nach mit "set myHmUART hmPairForSec 600" gepairt.
Dann einige Fernsterkotakte ebenfalls gepairt mit "set myHmUART hmPairForSec 600". Als ich dann die Fensterkontakte mit den Heizkörperthermostaten direkt an den beiden Geräten peeren wollte kamm die Fehlermeldung F4 und damit die Info, dass das nicht möglich ist weil die Teile schon an einer Zentrale gepairt sind.
Dann hab ich in FHEM und in den Geräten erst mal alles zurück gesetzt um zunächst die Fensterkontakte mit den Heizkörperthermosten zu peeren und anschließend die Thermostate mit fhem zu pairen.
Als dann die Wandthermostate da waren konnte ich diese wieder nicht mit den Heizungsthermostaten peeren weil die ja schon mit fhem verbunden waren.
Nun bin ich soweit, dass ich die Wandthermostate zunächst mit den Thermostaten gepeert habe und dann die Fensterkontakte ebenfalls mit dem Wandthermostaten gepeert. Dann nur das Wandthermostat mit fhem gepairt. Ist aber auch Müll weil ich neue Komponenten dann wieder nicht peeren kann.
Durch dieses Thema hab ich nun erfahren, dass der erste Ansatz doch irgendwie der richtige sein muss:
Alle Komponenten einfach mal mit fhem pairen und dann alle peerings über Befehle in fhem realisieren.
Inzwischen herrscht aber ein relativ großes Chaos durch das "löschen und neu pairen" was wohl auch nicht sauber gemacht wurde.
Jetzt überlege ich nochmal von vorne anzufangen und an den Geräten ein Reset zu machen.
Die Frage ist, wie bekomme ich alle HM_-Komponenten in fhem "gereinigt"?
Das ganze ist wirklich sehr verwirrend!
So sieht der Bereich CUL_HM im Augenblick aus:
CUL_HM
ActionDetector alive:10 dead:5 unkn:0 off:0
HM_569603_ClimaTeam unpeered
HM_569603_Climate unpeered
HM_569603_Weather 25.5
HM_569603_WindowRec last:trigLast
HM_569603_remote unpeered
HM_569604_ClimaTeam unpeered
HM_569604_Climate unpeered
HM_569604_Weather 20.5
HM_569604_WindowRec last:HM.Fenster_Bad:closed
HM_569604_remote unpeered
HM_56960A_Clima ???
HM_56960A_ClimaTeam ???
HM_56960A_Climate ???
HM_56960A_Weather ???
HM_56960A_WindowRec ???
HM_56960A_remote ???
HM_56960E_Clima ???
HM_56960E_ClimaTeam unpeered
HM_56960E_Climate unpeered
HM_56960E_Weather 23.0
HM_56960E_WindowRec last:trigLast
HM_56960E_remote unpeered
HM_569ACF_ClimaTeam unpeered
HM_569ACF_Climate unpeered
HM_569ACF_Weather 25.4
HM_569ACF_WindowRec last:trigLast
HM_569ACF_remote unpeered
HM_569AD8_ClimaTeam unpeered
HM_569AD8_Climate unpeered
HM_569AD8_Weather 16.4
HM_569AD8_WindowRec last:trigLast
HM_569AD8_remote unpeered
HM_569ADC_ClimaTeam unpeered
HM_569ADC_Climate unpeered
HM_569ADC_Weather 17.5
HM_569ADC_WindowRec last:HM.Fenster_Kueche:closed
HM_569ADC_remote unpeered
HM_5AE9A5_Btn_01 short 1_6 (to myHmUART)
HM_5AE9A5_Btn_02 LongRelease 1_16 (to myHmUART)
HM_5AE9A5_Btn_03 Short 1_6 (to myHmUART)
HM_5AE9A5_Btn_04 Short 1_8 (to myHmUART)
HM_5FA779_Clima ???
HM_5FA779_ClimaTeam ???
HM_5FA779_Climate set_desired-temp 23.0
HM_5FA779_Weather ???
HM_5FA779_WindowRec ???
HM_5FA779_remote ???
HM_618423_Climate T: 23.3 desired: 24.0
HM_618423_SwitchTr unpeered
HM_618423_Weather T: 23.3 H: 45
HM_618423_WindowRec last:trigLast
HM_618423_remote unpeered
HM_61842F_Climate T: 23.5 desired: 21.0
HM_61842F_SwitchTr unpeered
HM_61842F_Weather T: 23.5 H: 44
HM_61842F_WindowRec last:HM_580E65:closed
HM_61842F_remote unpeeredLeider bekomme ich es nicht hin, dass die Zeilen so wie sie in fhem angezeigt werden auch hier formatiert werden daher hab ich mal grob
nach formatiert.
LG
Wolfgang
Hallo Wolfgang,
Hurra, ich kann etwas zurück geben :)
Fehlermeldung F4, ja die hatte ich auch.
Bedeutet, das deine Komponenten schon mit deiner Zentrale gepairt sind, dann ist ein peeren der Komponenten untereinander nicht mehr möglich.
Ab da muss das peeren der Komponenten über die Zentrale gemacht werden.
Mein Weg war am Ende recht einfach, ich hatte ja alles schon untereinander gepeert, bevor ich die Zentrale mit den Komponenten gepairt hatte.
Einziges Problem in meinem Fall waren die neuen optischen Fensterkontakte, die die AES Verschlüsselung benötigen, nachdem ich AES auf dem Raspi nachinstalliert hatte, waren diese Fensterkontakte auch sofort eingebunden.
Ich würde meine Vorgehensweise empfehlen.
1. die Komponenten, die mit einander zu tun haben ohne Zentrale untereinander peeren, Nach Bedienungsanleitung.
z.B. Wohnzimmer Heizkörperthermostat, Wandthermostat und Fensterkontakt.
2. Das gleiche für Schlafzimmer, Kinderzimmer usw.
Wenn die sich untereinander verstehen und das tun was sie sollen, geht es mit Punkt 3 weiter.
3. Erst jetzt alle Komponenten nach und nach mit der Zentrale Pairen.
Es kann sein das nicht alles sofort komplett mit der Zentrale gepairt wird, einfach das Pairing wiederholen und über getConfig den Geräten die letzten Geheimnisse entlocken.
Und man muss Geduld haben, ich mit meinem Eigenbau-CUL-Stick habe ich einzelne Komponenten mehrfach Pairen lassen, bis alles okay war.
Ich hoffe das hilft ein wenig ?!?!?
EDIT:
okay vergessen .....
Die Komponenten aus FHEM löschen, sollte über den Link ganz unten in der DeviceOverview " Delete this device (HM_51A418)" gehen und danach auf die Schaltfläche links oben SAVE CONFIG ? klicken ....
Hallo Mike,
besten Dank erst mal.
Das Problem ist aber, das du auf diese Art später am Wandthermostat nichts mehr nachträglich anmelden (peeren) kannst sondern nur noch über fhem!
Ich habe jetzt z.B. im Wohnzimmer noch keine Fensterkontakte gepeert und müsste das noch tun.
Das geht aber nur über fhem und da stelle ich mir die Frage ob es nicht sinnvoller ist gleich grundsätzlich nach dieser Strategie vorzugehen.
Wenn man alles mischt dann bekommt man das Chaos das ich jetzt habe und das erst mal aufgeräumt werden muss!
Irgendwie bin ich der Meinung, dass ich vorher nicht so viele Zeilen in CUL_HM hatte.
LG
Wolfgang
Hallo Wolfgang,
ja du hast Recht, wenn die Zentrale gepairt ist, müssen ab da an alle neuen Geräte über die Zentrale (FHEM) gepeert werden.
Die Befürchtung, dass alles in einem Chaos endet wenn man erst die Komponenten untereinander peert dann an die Zentrale anmeldet und neue Geräte dann nur noch über die Zentrale einbinden, hatte ich auch, ist aber unbegründet.
Wie die peers entstanden sind, ist FHEM später egal, nach dem Pairen mit FHEM, sind auch FHEM die alten (vor FHEM entandenen) peers bekannt.
Das Spätere peeren über FHEM ist allerdings recht einfach, da hatte ich auch das Erlebnis, ach so einfach ist das .......
Die alten Hasen dürfen mich gerne verbessern oder es besser erklären ;)
hallo Mike,
gib deinem cul mal das attribut hmId => F11234. dann sollte der configcheck besser werden.
eine vccu, ist immer eine gute idee, hätte das automatisch für dich erledigt.
Hallo Frank,
ja, jetzt schaut die checkConfig aber deutlich besser aus.
configCheck done:
trigger sent to unpeered device
triggerUnpeered: HM_56AD6C:F11234
triggerUnpeered: HM_56AD88:F11234
trigger sent to undefined device
triggerUndefined: HM_56AD6C:F11234
triggerUndefined: HM_56AD88:F11234
Danke für den Tipp, gleich mal notieren, damit ich ihn fürs nächste mal parat habe :)
beste Grüße
Mike