Ich habe heute meinen 4x MapleCUN in Betrieb genommen und ein 433 Chip auf WMBUS_T gesetzt:
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz*
CUL2_MSGCNT 288
CUL2_TIME 2017-11-26 10:57:24
Clients :WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF CUL1
IODev CUL1
MessageEncoding CUL
NAME CUL2
NOTIFYDEV CUL1
NR 29
NTFY_ORDER 50-CUL2
PARTIAL
RAWMSG b32446850563722346980EB45A0119F21C905A037B004F308140A8CC55B8E00C5795F400800000000000000223718FF883F301B41917234440FCB4F8118
RSSI -62
STATE Initialized
StackLevel 1
TYPE STACKABLE_CC
VERSION V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 433MHz)
initString X21
brt
MatchList:
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
J:WMBUS ^b.*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-11-26 09:39:03 cmds b C F i A Z N E G M K L U Y R T V W X f z *
2017-11-26 10:57:24 state Initialized
Attributes:
rfmode WMBus_T
dann habe ich einen Techem Heizkostenverteiler definiert mit der Zahl des Displays (n3756 - laut Techem die Verteilernummer (https://www.techem.de/ueber-techem/haeufig-gestellte-fragen/heizkostenverteiler.html)):
Internals:
CFGFN
DEF 3756
NAME Techem_HKV_Test
NR 123
NTFY_ORDER 50-Techem_HKV_Test
STATE ???
TYPE TechemHKV
Attributes:
Allerdings passiert nichts mit dem HKV. Was passiert: ich bekomme viele Geräte von WMBUS mittels Autocreat angelegt, welche allerdings alle folgenden Fehler haben:
Unsupported CI Field a2, remaining payload is oder Unsupported CI Field a0, remaining payload is
Natürlich habe ich FHEM auf dem neusten Stand und auch neugestartet. Aber leider finde ich den Fehler nicht.
Techem hkv erwartet ein CUL. CUN werden nicht gelesen.
Verdammt, das war mit ein Grund warum ich ihn besorgt habe :D Und an wie müsste ich vorgehen, dass das auch unterstützt wird?
Alles eine Frage von angemessener Bestechung ;)
Traust du dir Änderungen im Modul zu ?
Naja ich habe rudimentäre Grundkenntnisse im Programmieren. Wenn du mir sagst nach was ich am besten Suche würde ich es versuchen. Bin natürlich gewillt zu helfen soweit mir möglich :)
Edit:
Gibt es ein Modul, welches CUL und CUN unterstützt? Dann würde ich dort anfange nach den Unterschieden zu suchen bzw. versuchen zu verstehen was passiert um es dann einsetzen zu können.
Kein Stress 😎
Ich schau später mal und mach einen Vorschlag. Du musst das halt testen
Kein Problem, testen bekomme ich normal hin.
Übrigens mit einem einfachen
return unless (($ntfyDev->{TYPE} eq 'CUL') || ($ntfyDev->{TYPE} eq 'Global') || ($ntfyDev->{TYPE} eq 'CUN')); ändern in der TechemHKV_Notify war es nicht getan :D
Wenn der TYPE eines CUN "CUN" lautet (bitte prüfen):
"müsste" (tm) es eigentlich reichen so etwas zu machen:
#90
return unless (($ntfyDev->{TYPE} eq 'CUL') || ($ntfyDev->{TYPE} eq 'Global'));
zu
return unless (($ntfyDev->{TYPE} =~ /CUL|CUN/ ) || ($ntfyDev->{TYPE} eq 'Global'));
#165
TechemHKV_IOPatch($hash, $d) if ($defs{$d}{TYPE} eq "CUL");
zu
TechemHKV_IOPatch($hash, $d) if ($defs{$d}{TYPE} =~ /CUL|CUN/ );
Da es ein Stackable_CC ist, gehe ich davon aus, dass ich es wie folgt ändern müsste:
#90
return unless (($ntfyDev->{TYPE} eq 'CUL') || ($ntfyDev->{TYPE} eq 'Global'));
zu
return unless (($ntfyDev->{TYPE} =~ /CUL|STACKABLE/ ) || ($ntfyDev->{TYPE} eq 'Global'));
#165
TechemHKV_IOPatch($hash, $d) if ($defs{$d}{TYPE} eq "CUL");
zu
TechemHKV_IOPatch($hash, $d) if ($defs{$d}{TYPE} =~ /CUL|STACKABLE/ );
Mit CUN hat sich nämlich nicht getan. Und ein List des "CUN" steht im ersten Post.
Edit:
Ja mit STACKABLE steht er nun auf listening :) War ich zu Beginn ja auf dem richtigen Weg. Ich danke dir und werde berichten, wie es sich weiter verhält.
ZitatMit CUN hat sich nämlich nicht getan. Und ein List des "CUN" steht im ersten Post.
Auch parallel gesehen, Du warst schneller :)
Da oben steht aber "STACKABLE_CC", das wäre wohl dann korrekt. Den Rest interpretierst Du korrekt.
hat ein CUN dann immer den TYPE "STACKABLE_CC" oder gibt es da verschiedene ? Wer kann das sagen ?
Zitat von: herrmannj am 26 November 2017, 14:20:51
Da oben steht aber "STACKABLE_CC", das wäre wohl dann korrekt. Den Rest interpretierst Du korrekt.
Das ist richtig, aber es gibt auch welche, die ohne CC arbeiten und wenn wir mittels =~ nur auf STACKABLE lauschen dann müsste ja beides gehen, oder?
Edit:
STACKABLE ist wohl die Unterart, wenn ein CUN mehrer Empfänger besitzt. Was der genau Unterschied zwischen normal und _CC ist habe ich noch nicht ganz verstanden. Ob es auch wirklich jemanden mit dem TYPE CUN gibt ist mir auch nicht bekannt. Mein CUN hat als Typ CUL, also der erste der angelegt wird.
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXeflptxz*
CUL1_MSGCNT 1034
CUL1_TIME 2017-11-26 14:23:48
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF 192.168.2.106:2323 4444
DeviceName 192.168.2.106:2323
FD 10
FHTID 4444
NAME CUL1
NR 28
PARTIAL
RAWMSG *b3244685055372234698094B8A0119F212C05A037B0004008C8091F47DBA800470400000600000000000002001413B41000000C080201002675DF1884D5
STACKED CUL2
STATE Initialized
TYPE CUL
VERSION V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) MapleCUNx4_8F (F-Band: 868MHz)
initString X21
MatchList:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-11-26 09:39:03 cmds B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
2017-11-26 14:23:48 state Initialized
Attributes:
Scheint soweit zu funktionieren:
Internals:
CFGFN
CUL2_MSGCNT 1
CUL2_RAWMSG b32446850563722346980EB45A0119F21C905A037B0043209A30A8CC5280E00C5795F400800000000000000223718FF883F301B41917234440FCB4F81::-61.5
CUL2_RSSI -61.5
CUL2_TIME 2017-11-26 14:22:17
DEF 3756
LASTInputDev CUL2
METER Funkheizkostenverteiler data IIl
MSGCNT 1
NAME Techem_HKV_Test
NR 123
NTFY_ORDER 50-Techem_HKV_Test
STATE listening
TYPE TechemHKV
VERSION 69
longID 34223756
READINGS:
2017-11-26 00:00:00 current_period 1200
2016-12-31 00:00:00 previous_period 1481
2017-11-26 14:19:32 state listening
2017-11-26 14:22:17 temp1 23.54
2017-11-26 14:22:17 temp2 27.23
Attributes:
ZitatWar ich zu Beginn ja auf dem richtigen Weg. Ich danke dir und werde berichten, wie es sich weiter verhält.
Absolut. Daumen hoch!
ZitatDas ist richtig, aber es gibt auch welche, die ohne CC arbeiten und wenn wir mittels =~ nur auf STACKABLE lauschen dann müsste ja beides gehen, oder?
Ja, allerdings würde ich die Ausdrücke noch präzisieren und Nebeneffekte auszuschließen. Wenn mal jemand einen "ESP_STACKABLE" erfindet der was ganz anderes macht haben wir sonst einen false-positive.
Schauen wir aber erst mal ob sich was tut. Ein HKV sendet, wenn ich mich richtig erinnere, alle 4-6 Minuten. Deine ID stimmt und passt zur RAW MSG in Deinem Post.
Zitat von: Amenophis86 am 26 November 2017, 14:25:36
Scheint soweit zu funktionieren:
Internals:
CFGFN
CUL2_MSGCNT 1
CUL2_RAWMSG b32446850563722346980EB45A0119F21C905A037B0043209A30A8CC5280E00C5795F400800000000000000223718FF883F301B41917234440FCB4F81::-61.5
CUL2_RSSI -61.5
CUL2_TIME 2017-11-26 14:22:17
DEF 3756
LASTInputDev CUL2
METER Funkheizkostenverteiler data IIl
MSGCNT 1
NAME Techem_HKV_Test
NR 123
NTFY_ORDER 50-Techem_HKV_Test
STATE listening
TYPE TechemHKV
VERSION 69
longID 34223756
READINGS:
2017-11-26 00:00:00 current_period 1200
2016-12-31 00:00:00 previous_period 1481
2017-11-26 14:19:32 state listening
2017-11-26 14:22:17 temp1 23.54
2017-11-26 14:22:17 temp2 27.23
Attributes:
Top! Wenn Du auf Kurs bleibst hast gegenüber 2016 die Chance zu sparen :)
Die Vorwerte sind leider nicht von uns sind, sind erst im März hier eingezogen. Aber im Vergleich zum Vormieter sparen ist ja auch schon was ;)
Jörg hast du eigentlich vor die Änderungen auf irgendeine Art zu übernehmen, oder muss ich vorerst das Modul aus update raus nehmen?
nö brauchst nicht. Die nehme ich gern auf.
vg
joerg
Top, dank dir.
Dachte nur, weil du noch mit STACKABLE unschlüssig warst, sollte da etwas anderes ähnliches irgendwann mal kommen. Wie gesagt aktuell arbeiten viele wohl noch mit STACKABLE_CC aber zukünftig soll wohl nur auf STACKABLE umgestellt werden (https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28alt.29). Aber das sehen wir dann, wenn es soweit ist und es nicht gehen sollte ;)
man wird sich melden ;)
Noch etwas, ich konnte jetzt alle bis auf einen HKV einbinden. Dieser will einfach nicht und scheint auch ein anderes Modell zu sein. Folgende RAW Msg konnte ich ihm über das Log zu ordnen:
2017-11-26_16:23:49 WMBUS_TCH_00568001_148_128 RSSI: -91.5
2017-11-26_16:23:49 WMBUS_TCH_00568001_148_128 LQI: 128
2017-11-26_16:23:49 WMBUS_TCH_00568001_148_128 Unsupported CI Field a2, remaining payload is 0f9f211202a03775041162090a0b40540054261a1b0000000000000000011706085875bcfaddbec08b
leider nimmt das definierte Gerät ihn nicht auf:
Internals:
CFGFN
DEF 8001
NAME Techem_HKV_KU
NR 597
NTFY_ORDER 50-Techem_HKV_KU
STATE A.:current_period P:previous_period Status:listening
TYPE TechemHKV
READINGS:
2017-12-10 18:18:53 state listening
Attributes:
room Z_Räume--Kueche
stateFormat A.:current_period P:previous_period Status:state
8001 ist aber sicher die Nummer, welche auf dem Display als ID ausgegeben wird und diese ID konnte ich auch im Log finden, wie oben geschrieben. Auch mit der 8digits ID konnte ich keine Daten für ihn empfangen. Eine Idee woran das liegt? Hier ein Bild, welches ich gefunden habe und genau zu dem HKV passt: https://www.techem.de/fileadmin/_processed_/b/c/csm_1740_FHKV_c0ff876efe.jpg
gib mal bitte eine komplette raw msg
Mmmmh wie kann ich eine Raw Msg ihm zuordnen? Ich erkenne die ID darin nicht. Die vom letzten Post hatte ich, weil es per Autocreat angelegt wurde und ich es so zuordnen konnte.
Edit:
Folgende Meldungen habe ich bisher geloggt:
2017-12-11_18:31:59 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804115B0C49124E0BF965006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85.5
2017-12-11_18:36:07 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411480C67114E75EF65006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85
2017-12-11_19:00:30 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411C60AD30D4E404265006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85
2017-12-11_19:04:33 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804118E0A600D4E33A365006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85.5
2017-12-11_19:08:35 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804115D0AF90C4E121765006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-86.5
2017-12-11_19:12:37 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411330A9C0C4EA90265006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85
2017-12-11_19:16:45 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411070A430C4ED49165006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85.5
2017-12-11_19:20:48 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411E009F60B4E81E665006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-89
2017-12-11_19:24:52 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411BB09AC0B4E7DD465006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-86
2017-12-11_19:28:54 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804119B09680B4EA7B665006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-86
2017-12-11_19:32:55 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804117A09290B4E2AC165006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85.5
2017-12-11_19:37:03 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804115C09EF0A4E155E65006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-90
2017-12-11_19:41:07 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804113E09B80A4EAFE265006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-87
2017-12-11_19:45:11 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E804111F09840A4ED3EC65006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-87
2017-12-11_19:49:13 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411EB08480A4ED5C165006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-88.5
2017-12-11_19:53:14 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411D4081B0A4EC17965006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-88
2017-12-11_19:57:22 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411C608E2094E439265006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85
2017-12-11_20:01:26 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411CE080D0D4ED7CD65006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-87
2017-12-11_20:05:30 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411B2091A114ECDA465006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-84
2017-12-11_20:09:32 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411CC0AFF114EB4D365006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-84.5
2017-12-11_20:13:33 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411990B48124E426965006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85
2017-12-11_20:17:41 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411070C56124E043865006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-84
2017-12-11_20:21:45 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411430C55124E9DD965006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-85.5
2017-12-11_20:25:49 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411490CB4114E581565006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-87.5
2017-12-11_20:29:50 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411FD0B81104E6D6265006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-89.5
2017-12-11_20:33:52 CUL2 UNKNOWNCODE b334468500180560094804C3AA20F9F211202B038E80411A30B5B0F4E919965006554261A1B000000000000000001DCBC1706085875BCFADDBEC0F25480::-86
Helfen dir die Daten, oder brauchst du etwas anders / mehr von mir?
Du hast das rein kopiert als ich den Beitrag schon gelesen hatte. Da bekomme ich keine Benachrichtigung mehr. Ich schau mal..
Habs mir fast gedacht, daher heute nochmal die Nachfrage in einer neuen Nachricht :) Dank dir.
ich glaube (tm) das ich das Model verstehe. Muss aber noch testen
Kein Problem, wenn ich dir irgendwie helfen kann gib Bescheid.
Moin
bitte teste den Anhang.
Zu den CUN/Stackable habe ich noch Fragen. In Deinem list aus dem ersten Post https://forum.fhem.de/index.php/topic,80145.msg721514.html#msg721514 heißt das Device CUL2, ist vom Type STACKABLE_CC und hat 433MHZ.
Im dem post https://forum.fhem.de/index.php/topic,80145.msg721610.html#msg721610 heißt das Device CUL1, Type CUL, 868MHZ
Ich habe den Stackable_cc noch nicht verstanden aber nach meinem Verständnis müsste doch auch ohne die Änderung auf "stackable" der CUL1 das richtige IO Device sein. ??
Kannst Du da nochmal Licht ins dunkel bringen ? Wenn meine Interpreation richtig ist würde ich das (dann unnötige) "stackable" wieder im modul entfernen um unbekannte Effekte auszuschließen.
Danke, vg
joerg
Zum besseren Verständnis, ich habe eine Platine auf der sind insgesamt 4 Sender/Empfänger. Zwei für 433 und zwei für 868 Mhz. Verbunden ist diese Platine aktuell mittels USB (Maple Mini Board) mit meinem PI3 auf dem FHEM läuft. Man kann es jedoch auch mittels LAN verbinden.
Definiert wird in FHEM der Chip, welcher als erster auf der Platine angelegt ist mittels define <CUL1> CUL ... Jeder weitere wird mittels define <CUL2> STACKABLE_CC .... Aus diesem Grund ist mein CUL1 ein 868 und auch ein Type CUL und der CUL2 ein Type STACKABLE_CC und hat 433 Mhz. Jeder Stackable gibt den CUL1 als IO Device an.
Orientiert habe ich mich an der CommandRef und am Wiki (https://wiki.fhem.de/wiki/MapleCUN). Funktioniert haben die Stackable erst mit deinem Modul, nachdem wir die Änderungen in den entsprechenden Zeilen vorgenommen haben.
Testen versuche ich die Tage zu machen. Ich danke dir schon mal für die neue Version.
lg Etienne
Bin jetzt endlich dazu gekommen die neue Version einzuspielen. Scheint zu funktionieren:
Internals:
CFGFN
CUL2_MSGCNT 1
CUL2_RAWMSG b334468500180560094804C3AA20F9F21120250393C05111B0A380C2A94497800786554261A1B00000000000000002192011706085875BCFADDBEC1EE80::-87
CUL2_RSSI -87
CUL2_TIME 2017-12-21 19:23:40
DEF 8001
LASTInputDev CUL2
LONGID 00568001
METER Funkheizkostenverteiler data III
MSGCNT 1
NAME Techem_HKV_KU
NR 338
NTFY_ORDER 50-Techem_HKV_KU
STATE A.:1340 P:530 Status:listening
TYPE TechemHKV
VERSION 94
READINGS:
2017-12-21 00:00:00 current_period 1340
2016-12-31 00:00:00 previous_period 530
2017-12-13 19:33:23 state listening
2017-12-21 19:23:40 temp1 25.87
2017-12-21 19:23:40 temp2 31.28
Attributes:
room Z_Räume--Kueche
stateFormat A.:current_period P:previous_period Status:state
Vielen Dank dafür.
Mir ist gerade aufgefallen, dass meine Daten nicht mehr aktualisiert werden, dann habe ich mir nochmal deinen Code angesehen. Du hast es auf eq 'CUL|STACKABLE') geändert. Das heißt aber, dass STACKABLE_CC nicht geht, daher wurden meine Geräte nicht mehr aktualisiert. Gibt es einen Grund, dass du nur noch auf STACKABLE und nicht auch auf STACKABLE_CC lauschen wolltest? Gibt sicher viele, die noch die CC Version nutzen.
mmmh habe jetzt nochmal auf {TYPE} =~ /CUL|STACKABLE/ und trotzdem kommen keine Daten mehr an. Im Eventmonitor sehe ich die Daten aber bei den Device ändert sich keins readings. Verstehe nicht warum nix ankommt. Habe an den Device selbst nix geändert und die gingen bis zum letzten FHEM Update am 23.12.
Ok, es hat was mit der Version für das neue hkv von dir im Post zutun. Sieht so aus, als ob es dafür noch die Readings erhält, aber alle anderen nicht mehr. Kann jetzt nicht mehr ausführlich testen, muss ich die Tage machen. Melde mich dann nochmal.
ich schau auch mal
Es liegt eindeutig an der neuen Version, habe die alte gerade nochmal eingespielt auf /CUL|STACKABLE/ geändert und es funktioniert sofort wieder alles, bis auf den HKV in der Küche, für welchen die Version geändert wurde. Habe mir auch mal die Unterschiede der alten und neuen Version angesehen, aber da fehlt mir leider doch das Verständnis für um direkt einen Fehler zu erkennen.
Edit:
Mir ist noch etwas aufgefallen. Als ich die alte Version wieder eingespielt habe, musste ich alle Device neu definieren bzw. mit defmod nochmals definieren, damit die Readings geändert werden. Ob ich das auch mit der neuen Version hätte machen müssen bei allen vorhandenen Device kann ich gerade nicht sagen und auch nicht mehr testen. Muss ich morgen, oder die Tage machen.
Noch eine Sache ich glaube in der neuen Version gibt es longID und LONGID als Internal, glaube nicht, dass das beabsichtigt ist.
Da waren in der Tat Fehler drin die Du gut gesehen hast. Thnx! Mangels Techem device ungetestet aber korrigierte Version.
So also aktuell kommen mit der Version sowohl beim neuen HKV, als auch bei den alten Daten an ohne, dass ich eines der Geräte neu definieren musste. Scheint also jetzt besser zu laufen. Werde es nochmal die Tage testen. Dank dir.
Ok schön. Danke. Wenn der Test ohne Vorfälle läuft checke ich es ein.
Habe heute nochmal bissi mit den HKVs gespielt und es sieht sehr gut aus. Konnte keine Fehler mehr ausmachen und sowohl bei den alten als auch dem neuen werden regelmäßig die Readings geschrieben.
Danke. im svn, ab morgen per update.
Guten Rutsch!
Ich danke dir.
Winterzeit = HKV Zeit. Mir ist noch was aufgefallen. Gestern ist kurzzeitig mit CUN weggewesen, so dass auch das IODevice für die HKVs weg war. Nachdem er wieder angechlossen war hat alles funktioniert, aber die HKVs sind alle auf "missing IODevice" geblieben. Liegt wohl daran, dass nach einem Verlust nicht automatisch geschaut wird, ob das IODevice wieder da ist. Habe bei allen ein Defmode ausgeführt und es hat sofort wieder funktioniert.
ja, das ist in der tat Richtig. oder Neustart.
Ok, dann werde ich mir ein notify mit defmod bauen. Dank dir.
Kurze Frage noch, werde aus dem Code nicht ganz schlau. Dieser Teil scheint ja wohl dafür verantwortlich zu sein:
# disable receiver
if (($e[0] eq 'ATTR') && ($e[2] eq 'rfmode') && ($e[3] ne 'WMBus_T')) {
readingsBeginUpdate($hash);
readingsBulkUpdate($hash, "state", "standby (IO missing)", 1);
Wenn ich jetzt einen Patch schreiben wollen würde, der automatisch schaut ob das Device wieder da ist, wo finde ich die Stelle, dass er mit der Meldung aufhört zu suchen? Weil eigentlich wird hier ja nur das Reading gesetzt aber finde den Teil nicht, dass nicht mehr weiter zugehört wird. Von meinem Verständnis müsste der CUL ja, sobald er wieder eine entsprechende Nachricht findet, auch diese wieder an das Modul weitergeben. Wird das irgendwo noch deaktiviert?