Moin,
ich habe Probleme beim Setzen vom Register shOnDly eines virtuellen Devices (timeControlPath_10) in einem HM-LC-BL1PBU-FM (Jalousie_KG_Tuer)
Dieses Register soll vom initialen Wert 0 auf 609 gesetzt werden.
set Jalousie_KG_Tuer regSet exec shOnDly 609 timeControlPath_10
Wert auf der Web-Oberfläche: R-timeControlPath_10-shOnDly set_600 s
Hier erscheint also ein falscher Wert 600, statt 609
Im Ergebnis wird nach einem getConfig ein Wert von 600 gesetzt. Ich vermute daher einen Fehler innerhalb von fhem.
Sniffer vom set-Befehl und anschließendem getConfig:
2020.07.10 13:35:01.784 1: ************** eyecatcher ***********************
2020.07.10 13:35:01.785 1: global version fhem.pl:22342/2020-07-04
2020.07.10 13:35:01.785 1: Jalousie_KG_Tuer model HM-LC-BL1PBU-FM
2020.07.10 13:35:01.786 1: Jalousie_KG_Tuer firmware 2.11
2020.07.10 13:35:01.786 1: Jalousie_KG_Tuer serialNr LEQ0608076
2020.07.10 13:35:01.786 1: HMLAN1 HMID 123ABC
2020.07.10 13:35:01.787 1: HMLAN2 HMID 123ABC
2020.07.10 13:35:01.787 1: Jalousie_KG_Tuer Reading powerOn 2020-07-08 14:40:46
2020.07.10 13:35:01.788 1: Jalousie_KG_Tuer protLastRcv 2020-07-10 13:30:53
2020.07.10 13:35:01.788 1: sniffer_01 for Jalousie_KG_Tuer now activ
2020.07.10 13:35:01.788 1:
2020.07.10 13:35:13.324 3: CUL_HM set Jalousie_KG_Tuer regSet exec shOnDly 609 timeControlPath_10
2020.07.10 13:35:13.327 0: HMLAN_Send: HMLAN1 S:S38820C21 stat: 00 t:00000000 d:01 r:38820C21 m:6F A001 123ABC 2CD4AF 0105FF00170B03
2020.07.10 13:35:13.640 0: HMLAN_Parse: HMLAN1 R:R38820C21 stat:0001 t:096D04B0 d:FF r:FFC8 m:6F 8002 2CD4AF 123ABC 00
2020.07.10 13:35:13.650 0: HMLAN_Send: HMLAN1 S:S38820D64 stat: 00 t:00000000 d:01 r:38820D64 m:70 A001 123ABC 2CD4AF 0108068A
2020.07.10 13:35:13.659 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083B8B15 d:FF r:FF98 m:6F A001 123ABC 2CD4AF 0105FF00170B03
2020.07.10 13:35:13.890 0: HMLAN_Parse: HMLAN1 R:R38820D64 stat:0001 t:096D0642 d:FF r:FFCB m:70 8002 2CD4AF 123ABC 00
2020.07.10 13:35:13.985 0: HMLAN_Send: HMLAN1 S:S38820E5D stat: 00 t:00000000 d:01 r:38820E5D m:71 A001 123ABC 2CD4AF 0106
2020.07.10 13:35:14.364 0: HMLAN_Parse: HMLAN1 R:R38820E5D stat:0001 t:096D07D4 d:FF r:FFCA m:71 8002 2CD4AF 123ABC 00
2020.07.10 13:35:45.725 3: CUL_HM set Jalousie_KG_Tuer getConfig
2020.07.10 13:35:45.727 0: HMLAN_Send: HMLAN1 S:S38828AB1 stat: 00 t:00000000 d:01 r:38828AB1 m:72 A001 123ABC 2CD4AF 00040000000000
2020.07.10 13:35:46.444 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D834A d:FF r:FFC9 m:72 A010 2CD4AF 123ABC 0202810A120B3A0CBC15021800
2020.07.10 13:35:46.481 0: HMLAN_Parse: HMLAN1 R:R38828AB1 stat:0001 t:096D834F d:FF r:FFC9 m:72 A010 2CD4AF 123ABC 0202810A120B3A0CBC15021800
2020.07.10 13:35:46.489 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D8440 d:FF r:FFC6 m:73 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:46.777 0: HMLAN_Send: HMLAN1 S:S38828ECB stat: 00 t:00000000 d:01 r:38828ECB m:74 A001 123ABC 2CD4AF 01040000000001
2020.07.10 13:35:46.790 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C09AA d:FF r:FF9A m:72 A001 123ABC 2CD4AF 00040000000000
2020.07.10 13:35:46.799 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C0AA5 d:FF r:FF99 m:72 8002 123ABC 2CD4AF 00
2020.07.10 13:35:46.807 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C0B9E d:FF r:FF9A m:73 8002 123ABC 2CD4AF 00
2020.07.10 13:35:47.074 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D8763 d:FF r:FFC7 m:74 A010 2CD4AF 123ABC 0308000000003200320500
2020.07.10 13:35:47.087 0: HMLAN_Parse: HMLAN1 R:R38828ECB stat:0001 t:096D8768 d:FF r:FFC7 m:74 A010 2CD4AF 123ABC 0308000000003200320500
2020.07.10 13:35:47.099 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C0DC6 d:FF r:FF9A m:74 A001 123ABC 2CD4AF 01040000000001
2020.07.10 13:35:47.106 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C0EC0 d:FF r:FF99 m:74 8002 123ABC 2CD4AF 00
2020.07.10 13:35:47.197 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D885E d:FF r:FFC7 m:75 A010 2CD4AF 123ABC 02300657065600
2020.07.10 13:35:47.318 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C0FB9 d:FF r:FF98 m:75 8002 123ABC 2CD4AF 00
2020.07.10 13:35:47.443 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D8954 d:FF r:FFC7 m:76 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:47.675 0: HMLAN_Send: HMLAN1 S:S3882924E stat: 00 t:00000000 d:01 r:3882924E m:77 A001 123ABC 2CD4AF 0103
2020.07.10 13:35:47.685 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C10B2 d:FF r:FF97 m:76 8002 123ABC 2CD4AF 00
2020.07.10 13:35:47.835 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C11BF d:FF r:FF99 m:77 A001 123ABC 2CD4AF 0103
2020.07.10 13:35:47.974 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D8B65 d:FF r:FFC7 m:77 A010 2CD4AF 123ABC 012CD4AF012CD4AF023AE5A907FF00170A
2020.07.10 13:35:48.081 0: HMLAN_Parse: HMLAN1 R:R3882924E stat:0001 t:096D8B6A d:FF r:FFC7 m:77 A010 2CD4AF 123ABC 012CD4AF012CD4AF023AE5A907FF00170A
2020.07.10 13:35:48.090 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C12BE d:FF r:FF99 m:77 8002 123ABC 2CD4AF 00
2020.07.10 13:35:48.813 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D8C63 d:FF r:FFC8 m:78 A010 2CD4AF 123ABC 01FF00170BFF00171E1111120100000000
2020.07.10 13:35:49.072 0: HMLAN_Send: HMLAN1 S:S388297C2 stat: 00 t:00000000 d:01 r:388297C2 m:79 A001 123ABC 2CD4AF 01041111120103
2020.07.10 13:35:49.247 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D905F d:FF r:FFC7 m:79 A010 2CD4AF 123ABC 030111111132C700FF00FF012222220000
2020.07.10 13:35:49.354 0: HMLAN_Parse: HMLAN1 R:R388297C2 stat:0001 t:096D9064 d:FF r:FFC7 m:79 A010 2CD4AF 123ABC 030111111132C700FF00FF012222220000
2020.07.10 13:35:49.501 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D915D d:FF r:FFC9 m:7A A010 2CD4AF 123ABC 0311C80000000000000000000011FF2200
2020.07.10 13:35:49.748 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9256 d:FF r:FFC7 m:7B A010 2CD4AF 123ABC 0381000000326400FF00FF201452630000
2020.07.10 13:35:49.997 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D934F d:FF r:FFC8 m:7C A010 2CD4AF 123ABC 0391C80000000000000000000000056300
2020.07.10 13:35:50.235 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D943D d:FF r:FFC8 m:7D A010 2CD4AF 123ABC 030000
2020.07.10 13:35:50.545 0: HMLAN_Send: HMLAN1 S:S38829D83 stat: 00 t:00000000 d:01 r:38829D83 m:7E A001 123ABC 2CD4AF 01042CD4AF0103
2020.07.10 13:35:50.556 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C1B9C d:FF r:FF98 m:7D 8002 123ABC 2CD4AF 00
2020.07.10 13:35:50.767 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D964F d:FF r:FFC8 m:7E A010 2CD4AF 123ABC 0301000000326400FF00FF015555600000
2020.07.10 13:35:50.874 0: HMLAN_Parse: HMLAN1 R:R38829D83 stat:0001 t:096D9654 d:FF r:FFC8 m:7E A010 2CD4AF 123ABC 0301000000326400FF00FF015555600000
2020.07.10 13:35:50.883 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C1DA9 d:FF r:FF98 m:7E 8002 123ABC 2CD4AF 00
2020.07.10 13:35:51.020 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D974D d:FF r:FFCA m:7F A010 2CD4AF 123ABC 0311C80000000000000000000000FF6000
2020.07.10 13:35:51.133 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C1EA2 d:FF r:FF99 m:7F 8002 123ABC 2CD4AF 00
2020.07.10 13:35:51.562 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D996C d:FF r:FFC9 m:80 A010 2CD4AF 123ABC 0381000000326400FF00FF219454930000
2020.07.10 13:35:51.675 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C20C1 d:FF r:FF96 m:80 8002 123ABC 2CD4AF 00
2020.07.10 13:35:51.811 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9A65 d:FF r:FFC8 m:81 A010 2CD4AF 123ABC 0391C80000000000000000000000049300
2020.07.10 13:35:51.924 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C21BA d:FF r:FF98 m:81 8002 123ABC 2CD4AF 00
2020.07.10 13:35:52.060 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9B53 d:FF r:FFCA m:82 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:52.373 0: HMLAN_Send: HMLAN1 S:S3882A4A7 stat: 00 t:00000000 d:01 r:3882A4A7 m:83 A001 123ABC 2CD4AF 01042CD4AF0203
2020.07.10 13:35:52.389 0: HMLAN_Parse: HMLAN2 R:E3AE5A9 stat:0000 t:083C231D d:FF r:FFA8 m:2D 8041 3AE5A9 2CD4AF 07190080
2020.07.10 13:35:52.807 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C24BF d:FF r:FF96 m:83 8002 123ABC 2CD4AF 00
2020.07.10 13:35:52.831 0: HMLAN_Parse: HMLAN1 R:E3AE5A9 stat:0000 t:096D9C38 d:FF r:FFB2 m:2D 8041 3AE5A9 2CD4AF 07190080
2020.07.10 13:35:52.940 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9D65 d:FF r:FFC9 m:83 A010 2CD4AF 123ABC 030100000032640000F8000122000300C8
2020.07.10 13:35:52.954 0: HMLAN_Parse: HMLAN1 R:R3882A4A7 stat:0001 t:096D9D6A d:FF r:FFC9 m:83 A010 2CD4AF 123ABC 030100000032640000F8000122000300C8
2020.07.10 13:35:53.365 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9E63 d:FF r:FFC8 m:84 A010 2CD4AF 123ABC 0311C80000000000000000000000FF0300
2020.07.10 13:35:53.388 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096D9F5C d:FF r:FFCB m:85 A010 2CD4AF 123ABC 0381000000326400FF00FF211812680000
2020.07.10 13:35:53.401 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA055 d:FF r:FFC7 m:86 A010 2CD4AF 123ABC 0391C80000000000000000000000046800
2020.07.10 13:35:53.568 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA143 d:FF r:FFCA m:87 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:53.824 0: HMLAN_Send: HMLAN1 S:S3882AA52 stat: 00 t:00000000 d:01 r:3882AA52 m:88 A001 123ABC 2CD4AF 01043AE5A90703
2020.07.10 13:35:54.101 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA355 d:FF r:FFC8 m:88 A010 2CD4AF 123ABC 030100000032640000F8FF011030280000
2020.07.10 13:35:54.208 0: HMLAN_Parse: HMLAN1 R:R3882AA52 stat:0001 t:096DA35A d:FF r:FFC8 m:88 A010 2CD4AF 123ABC 030100000032640000F8FF011030280000
2020.07.10 13:35:54.217 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C2AAF d:FF r:FF97 m:88 8002 123ABC 2CD4AF 00
2020.07.10 13:35:54.353 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA453 d:FF r:FFC7 m:89 A010 2CD4AF 123ABC 0311C80000000000000000000000FF2000
2020.07.10 13:35:54.469 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C2BA8 d:FF r:FF99 m:89 8002 123ABC 2CD4AF 00
2020.07.10 13:35:54.602 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA54C d:FF r:FFCA m:8A A010 2CD4AF 123ABC 0381000000326400FF00FF201452630000
2020.07.10 13:35:54.716 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C2CA1 d:FF r:FF9A m:8A 8002 123ABC 2CD4AF 00
2020.07.10 13:35:54.851 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA645 d:FF r:FFC7 m:8B A010 2CD4AF 123ABC 0391C80000000000000000000000056300
2020.07.10 13:35:54.964 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C2D9A d:FF r:FF99 m:8B 8002 123ABC 2CD4AF 00
2020.07.10 13:35:55.089 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA733 d:FF r:FFC9 m:8C A010 2CD4AF 123ABC 030000
2020.07.10 13:35:55.344 0: HMLAN_Send: HMLAN1 S:S3882B042 stat: 00 t:00000000 d:01 r:3882B042 m:8D A001 123ABC 2CD4AF 0104FF00170A03
2020.07.10 13:35:55.622 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DA946 d:FF r:FFC7 m:8D A010 2CD4AF 123ABC 030100221280FF0000F8FF012055000000
2020.07.10 13:35:55.728 0: HMLAN_Parse: HMLAN1 R:R3882B042 stat:0001 t:096DA94B d:FF r:FFC7 m:8D A010 2CD4AF 123ABC 030100221280FF0000F8FF012055000000
2020.07.10 13:35:55.875 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DAA44 d:FF r:FFC6 m:8E A010 2CD4AF 123ABC 0311C80000000000000000000002FF0000
2020.07.10 13:35:56.123 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DAB3D d:FF r:FFC9 m:8F A010 2CD4AF 123ABC 0381000000326400FF00FF211452630000
2020.07.10 13:35:56.238 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3292 d:FF r:FF9A m:8F 8002 123ABC 2CD4AF 00
2020.07.10 13:35:56.372 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DAC36 d:FF r:FFC7 m:90 A010 2CD4AF 123ABC 0391C80000000000000000000000056300
2020.07.10 13:35:56.609 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DAD24 d:FF r:FFC7 m:91 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:56.864 0: HMLAN_Send: HMLAN1 S:S3882B632 stat: 00 t:00000000 d:01 r:3882B632 m:92 A001 123ABC 2CD4AF 0104FF00170B03
2020.07.10 13:35:56.874 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3484 d:FF r:FF9A m:91 8002 123ABC 2CD4AF 00
2020.07.10 13:35:57.008 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3596 d:FF r:FF99 m:92 A001 123ABC 2CD4AF 0104FF00170B03
2020.07.10 13:35:57.141 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DAF36 d:FF r:FFC7 m:92 A010 2CD4AF 123ABC 030100000032648AFF00FF001452630000
2020.07.10 13:35:57.248 0: HMLAN_Parse: HMLAN1 R:R3882B632 stat:0001 t:096DAF3B d:FF r:FFC7 m:92 A010 2CD4AF 123ABC 030100000032648AFF00FF001452630000
2020.07.10 13:35:57.394 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB034 d:FF r:FFC7 m:93 A010 2CD4AF 123ABC 0311C80000000000000000000000FF6300
2020.07.10 13:35:57.511 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3789 d:FF r:FF96 m:93 8002 123ABC 2CD4AF 00
2020.07.10 13:35:57.643 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB12D d:FF r:FFC9 m:94 A010 2CD4AF 123ABC 0381000000326400FF00FF201452630000
2020.07.10 13:35:57.755 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3882 d:FF r:FF99 m:94 8002 123ABC 2CD4AF 00
2020.07.10 13:35:57.891 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB226 d:FF r:FFC6 m:95 A010 2CD4AF 123ABC 0391C80000000000000000000000056300
2020.07.10 13:35:58.005 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C397B d:FF r:FF99 m:95 8002 123ABC 2CD4AF 00
2020.07.10 13:35:58.129 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB314 d:FF r:FFC7 m:96 A010 2CD4AF 123ABC 030000
2020.07.10 13:35:58.384 0: HMLAN_Send: HMLAN1 S:S3882BC22 stat: 00 t:00000000 d:01 r:3882BC22 m:97 A001 123ABC 2CD4AF 0104FF00171E03
2020.07.10 13:35:58.394 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3A74 d:FF r:FF99 m:96 8002 123ABC 2CD4AF 00
2020.07.10 13:35:58.527 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3B86 d:FF r:FF97 m:97 A001 123ABC 2CD4AF 0104FF00171E03
2020.07.10 13:35:58.661 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB526 d:FF r:FFC6 m:97 A010 2CD4AF 123ABC 03010000023264F8F8F8580126340800C8
2020.07.10 13:35:58.768 0: HMLAN_Parse: HMLAN1 R:R3882BC22 stat:0001 t:096DB52B d:FF r:FFC6 m:97 A010 2CD4AF 123ABC 03010000023264F8F8F8580126340800C8
2020.07.10 13:35:58.778 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3C80 d:FF r:FF98 m:97 8002 123ABC 2CD4AF 00
2020.07.10 13:35:58.919 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB624 d:FF r:FFC7 m:98 A010 2CD4AF 123ABC 0311C80000000000000000000000FF0200
2020.07.10 13:35:59.027 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3D79 d:FF r:FF99 m:98 8002 123ABC 2CD4AF 00
2020.07.10 13:35:59.165 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB71D d:FF r:FFC8 m:99 A010 2CD4AF 123ABC 0381000000326400FF00FF201452630000
2020.07.10 13:35:59.411 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB816 d:FF r:FFC6 m:9A A010 2CD4AF 123ABC 0391C80000000000000000000000056300
2020.07.10 13:35:59.525 0: HMLAN_Parse: HMLAN2 R:E123ABC stat:0000 t:083C3F6B d:FF r:FF99 m:9A 8002 123ABC 2CD4AF 00
2020.07.10 13:35:59.649 0: HMLAN_Parse: HMLAN1 R:E2CD4AF stat:0000 t:096DB904 d:FF r:FFC7 m:9B A010 2CD4AF 123ABC 030000
2020.07.10 13:36:10.808 1:
2020.07.10 13:36:10.809 1: sniffer_01 stopped
2020.07.10 13:36:10.810 1: Jalousie_KG_Tuer Reading powerOn 2020-07-08 14:40:46
2020.07.10 13:36:10.811 1: Jalousie_KG_Tuer protLastRcv 2020-07-10 13:35:59
2020.07.10 13:36:11 3: logging set to
2020.07.10 13:36:11 3: attr HMLAN1 logIDs off : logging set to
2020.07.10 13:36:11 3: logging set to
2020.07.10 13:36:11 3: attr HMLAN2 logIDs off : logging set to
2020.07.10 13:36:11 1: sniffer_01 ended
2020.07.10 13:36:11 1: ************** eyecatcher ***********************
Anschließend set Jalousie_KG_Tuer regSet exec shOnDly 700 timeControlPath_10; => ergibt einen Wert von 660
Anschließend set Jalousie_KG_Tuer regSet exec shOnDly 1000 timeControlPath_10; => ergibt einen Wert von 960
Anschließend set Jalousie_KG_Tuer regSet exec shOnDly 609 timeControlPath_10 => ergibt einen Wert von 600
Test mit shOffDly ergibt das gleiche Verhalten.
Könnte bitte jemand helfen, ich kann mit den Snifferdaten nix anfangen ?
Moin und vielen Dank vorab
Bernd
Das dürfte "normal" sein...
Das dahinterliegende Problem ist, dass die Zeiten in den HM-Aktoren allgemein vercodet sind und mit steigender Dauer immer "ungenauer" werden. Ergo dürfte das Modul das "präventiv" berücksichtigen und nur "zulässige" (aber eben "naheliegende", nicht "genaue") Dauern senden, weil sonst was völlig schräges zurückkäme (dann vermutlich 660 Sekunden oder so...). (Leider finde ich die passende Fundstelle nicht auf die Schnelle, aber das Thema kommt so alle 12-24 Monate mal wieder).
Moin,
das hört sich für mich "komisch" an.
Ich glaube aber, das der Bug innerhalb von fhem zu suchen ist.
Zitatset Jalousie_KG_Tuer regSet exec shOnDly 609 timeControlPath_10
Wert auf der Web-Oberfläche: R-timeControlPath_10-shOnDly set_600 s
Auf den Befehl set regset... 609... kommt in der Anzeige im Web schon set_to 600.
Es ist imo kein "bug". Da Modul prüft deine Eingabe, stellt fest, dass es nicht exakt so umzusetzen ist wie gewünscht (weil die Hardware es nicht kann), macht daraus was, was die Hardware kann und signalisiert dann dir als User, was es letztendlich mit deinem Wunsch angestellt hat (bzw. nach Quittierung durch den Aktor: Was der verstanden hat).
Es nützt ja nichts, wenn du dem Aktor mit einem "bugfreien" Modul eine exakte Angabe senden kannst, der aber am Ende "nichts" macht, weil er gar nicht versteht, was du von ihm willst...
Die in 10_CUL_HM definierten Funktionen CUL_HM_encodeTime8 und CUL_HM_decodeTime8 wandeln den Zahlenraum in einen 3-bit-Multiplikator und einen 5-bit-Wert um. Während letzterer direkt die Werte 0...31 abbildet, ist ersterer eine Definition: 0..7 entsprechen den Werten 0.1, 1, 5, 10, 60, 300, 600 und 3600 Sekunden.
Oberhalb von 310 s (=10*31) geht es folglich nur noch in 60er Schritten weiter. Wunschwerte werden abgerundet, so wird aus 609 eben 60*10, aus 700 60*12, aus 1000 60*16. Das geht so bis 60*31=1860, der nächste Wert ist dann erst 300*7=2100 ... usw ...
So kann man Zeiten in variabler Staffelung bis 111600 s in nur einem Byte speichern.
mmm|wwwww als Beispiel: Für 600 Sekunden sind das 60*10, 60s-Stufe ist binär 100, daran kommt 01010 = 0x0A = 10 , zusammen sind das 0x8A. 0x8B ist dann 60*11=660 usw... bis 60*31 = 100|11111 bzw. 0x9F. Ab da braucht es die nächste Stufe 101|xxxxx mit 101|00001 bzw 0xA1 = 300. Der nächste mögliche Wert nach 60*31 = 1860 (binär 10011111 = 0x9F) ist dann 300*7=2100 bzw. 0xA7.
Die Kodierung ist nicht eindeutig: 1800 ließen sich als 0xA6 (300*6) und 0x9E (60*30) darstellen.
edit: Fehler in Multiplikatortabelle und Beispiel korrigiert
Hi,
bei HM Wired werden zwei bit für den Multiplikator genommen. "11000000 00000000" Der Rest für den eigentlichen Wert. Bei Funk ist es etwas anders.. aber die Sprünge, die Pfriemler erklärt hat sind aber ebenfalls dadurch geschuldet.
Die Device XML defniert das so (z.B. HMW-LC-Dim1L-DR)
<conversion type="float_configtime" factors="0.1,1,60,1000" value_size="1.6"/>
<conversion type="integer_integer_map">
<value_map device_value="0xc000" parameter_value="0xffff" mask="0xc000"/>
Gruß,
Thomas
Pfriemler hat es sehr schön erklart. Ein paar Ergänzungen vom Klugscheißer
100|11111 sind nicht 0x8f sondern natürlich 0x9f
Der Wertebereich geht also von 1... 511
Multiplikatoren sein
1s, => Bereich 1s bis 511s =8min31s
2s, => Bereich 2s bis 1022s =17min2s
5s, => Bereich 5s bis 2555s = 42min35s
10s, => Bereich 10s bis 5110s = 1h25min10s
1min, => Bereich 1min bis 511min = 8h31min0s
5min, => Bereich 5min bis 2555min =1d18h35min0s
10min => Bereich 10min bis 5110min = 3d13h10min0s
1h, => Bereich 1h bis 511h = 21d7h0min0s
Der erste Wert ist natürlich die Schrittweite.
Den 21 Tage wert habe ich nie getestet :)
Ja, das war ein Schreibfehler, 9F ist richtig.
Es fehlt noch eine kleine Wahrheit: Der Multiplikator 000 hat den Sekundenwert 0.1 (und 2 gibt es gar nicht, habe mich vertan):
Line 8607: my @culHmTimes8 = ( 0.1, 1, 5, 10, 60, 300, 600, 3600 );
Die sub CUL_HM_decodeTimes8 nutzt diese "Tabelle" bei der Umrechnung. Was ich noch nicht kapiere: CUL_HM_encodeTimes8 liefert immer den nächsthöheren möglichen Wert, nicht den kleineren. Aber das ist in diesem Fall ja nebensächlich, es ging ja nur um die Klärung der möglichen Werte.
Aber Martin: Der Wertebereich hat nur 5, nicht 9 bits, und geht daher nicht bis 511, sondern nur bis 31:
Der Wertebereich geht also von 1...31, daraus ergeben sich folgende Zeitstaffeln:
Multiplikator/Schrittweite => genutzt von ... bis
0.1s, => 0.1s bis 3.1s
1s, => 3.2 bis 31s
5s, => 31.1 bis 155s = 2min35s
10s, => 155.1 bis 310s = 5min10s
1min, => 310.1s bis 31min
5min, => >31min bis 155min = 2h35min
10min => 155min bis 310min = 5h10min
1h, => >310min bis 30h (!!)
Der letztmögliche Wert wäre 31h (3600*31s), wird aber als "dauerhaft" von der Hardware interpretiert und in FHEM in "unused" übersetzt.
Nachtrag: Ich muss wirklich gestehen, dass ich mich ohne diesen Thread nie mit der Problematik auseinandergesetzt hätte. Das erklärt jetzt aber auch einiges.
Außerdem scheint es da evtl einen Bug zu geben: Ich bekomme den Wert 31 nicht gesetzt: Aus 1860s (60*31) werden 1800s, ebenso 1861 springt auf 1800 statt 1860 zurück, obwohl es nach der Staffel möglich wäre. Oder aber 31 als Multiplikator wird von der Hardware generell nicht akzeptiert.
Martin?
Moin,
hoppala und sorry - mir war nicht klar, dass für diese reg nur 1 Byte im Transferprotokoll vorgesehen ist. Insofern konnte ich mir nicht vorstellen, wieso aus 609 "plötzlich" 600 geworden ist.
Wieder etwas gelernt,
danke für Eure tollen Infos !!Habe mal rumgespielt:
{CUL_HM_encodeTime8(609)} => 8B
{CUL_HM_decodeTime8('8B')}; => 660
Beim regset wird daraus aber 600. Das scheint diese Sache mit der Rundung zu sein.
ZitatWas ich noch nicht kapiere: CUL_HM_encodeTimes8 liefert immer den nächsthöheren möglichen Wert, nicht den kleineren.
Wo passiert diese Rundung ? Da ich mehr als Entwickler meiner Anwendungen fürs Haus aktiv bin und dabei zur Risikominimierung möglichst viel mit peering arbeite, denke ich an so eine Art "value-checker". Will nicht immer erst durch tatsächliche Registeränderung den richtigen Wert erfahren.
Prinzip :
{CUL_HM_decodeTime8(CUL_HM_encodeTime8(609))}Wenn da noch die Rundung rein käme, wär das komplett. Ich finde das aber leider nicht in der 10_CUL_HM
Tatsächlich geht das Abrunden bis 653 auf 600 und Aufrunden ab 654 auf 660.
Moin
Bernd
ich würde es begrüssen, wenn solche codierungen unter "get regList" unter description auftauchen würden.
Zitat von: pwlr am 11 Juli 2020, 11:52:21
Wenn da noch die Rundung rein käme, wär das komplett. Ich finde das aber leider nicht in der 10_CUL_HM
Tatsächlich geht das Abrunden bis 653 auf 600 und Aufrunden ab 654 auf 660.
Die Konvertierung der Zeiten für eine regSet-Operation findet in zwei anderen Funktionen statt:
{CUL_HM_CvTflt(CUL_HM_fltCvT(xxx))}ist Dein Freund. xxx ist der zu konvertierende Wert. Dein 653/654s-Versuch liefert korrektes Ergebnis.
P.S.: diese Funktion liefern und erwarten Dezimalwerte, die in HEX denen von en/decodeTime8 entsprechen.
@frank: Könntest Du das eventuell als Prüfung beim Ändern von Zeiten in hm.js einbauen?
Also wenn man einen Registerwert ändert und das Eingabefeld verlässt, den Wert so gegenkorrigieren?
Das betrifft alle Register, für die in HMConfig.pm ein "c=>'fltCvT'" definiert ist.
(Natürlich gibt es noch mehr Konversionen (fltCvt60,min2time) als diese ...)
Zitat von: Pfriemler am 11 Juli 2020, 14:51:12
@frank: Könntest Du das eventuell als Prüfung beim Ändern von Zeiten in hm.js einbauen?
Also wenn man einen Registerwert ändert und das Eingabefeld verlässt, den Wert so gegenkorrigieren?
Das betrifft alle Register, für die in HMConfig.pm ein "c=>'fltCvT'" definiert ist.
(Natürlich gibt es noch mehr Konversionen (fltCvt60,min2time) als diese ...)
wenn man eine fertige und passende funktion aus get regList parsen kann, könnte das funktionieren.
Moin,
Pfriemler, wieder mal Danke !
Hier ein einfacher Checker für den "Hausgebrauch" auf Basis eines dummy.
define regSet_interval_checker dummy
attr regSet_interval_checker comment Umrechnung der Registerwerte für Zeitkonstanten\
Hilfsroutine für Anwendungsentwicklung\
\
see https://forum.fhem.de/index.php/topic,112788.0.html\
CUL_HM_CvTflt(xxx)\
CUL_HM_fltCvT(xxx)\
attr regSet_interval_checker event-on-update-reading .*
attr regSet_interval_checker group Debugging
attr regSet_interval_checker room -System
attr regSet_interval_checker userReadings translationValue {CUL_HM_CvTflt(CUL_HM_fltCvT(ReadingsVal($name,"state",0)))}
Moin
Bernd
Ich hadere im Moment noch immer mit Werten rund um den Wert 31.
1860 wäre der letztmögliche Wert für 60s*31.
1859 rundet auf 1860.
1861 rundet auf 1800. Das liegt an der Art der Bereichsermittlung in CUL_HM_fltCvT.
1860 rundet aber sinnloserweise auch auf 1800. Das ließe sich mit einem <= allda einfach beheben.
Noch habe ich keine Idee, wie man da sinnvoll auf- oder abrundet.
btw. Eine Aufrundung auf den nächsten Wert erfolgt immer dann, wenn der Wunschwert 10% unter dem nächsthöheren möglichen liegt. Siehe CUL_HM_fltCvT.
Hier gibts nichts Neues, oder?
Da ich unabhängig von diesem Thread das Problem hatte, wissen zu wollen, wie die Timerauflösungen genau sind, habe ich nach etwas Beschäftigung mit der Materie einen Wikiartikel
https://wiki.fhem.de/wiki/HomeMatic_Timerwerte (https://wiki.fhem.de/wiki/HomeMatic_Timerwerte)
verfasst, der aber zum Thema Rundung notgedrungen äusserst vage ist.
Wenn jemand inzwischen erklären kann, was es mit Wert 31 auf sich hat, bzw. warum z.b. 1859s zwar auf 1860s rundet, 1860s aber auf 1800s, dann könnte die Person den Artikel ja entsprechend umschrieben. Ich rieche ja irgendeine Ungenauigkeit in der Funktion in cul_hm bzw der Bereichsermittlung, bin aber zu unfähig die zu erkennen, obwohl ich mir den Code der das machen soll angesehen habe.
Du "riechst" richtig. Die Ungenauigkeit ist da beheimatet.
Bevor das Rad neu erfunden wird, würde ich da aber zunächst wissen wollen wie eine CCU damit umgeht. Dann entscheiden ob man das übernimmt (ich denke dass es anfangs so war, aber ob eine möglicherweise dort erfolgte Korrektur auch übernommen wurde) und erst danach überlegen ob man es genauer berechnen kann und ob die Geräte das auch verarbeiten.
Dann ggf. Martin zur Korrektur vorschlagen und dann dokumentieren. Aktuell fehlen mir dazu Zeit und CCU :(
Zitat von: Zrrronggg! am 09 März 2021, 22:43:55
Da ich unabhängig von diesem Thread dasProblem hatte, wissen zu wollen, wie die Timerauflösungen genau sind, habe ich nach etwas Beschäftigung mit der Materie einen Wikiartikel
https://wiki.fhem.de/wiki/HomeMatic_Timerwerte (https://wiki.fhem.de/wiki/HomeMatic_Timerwerte)
verfasst, der aber zum Thema Rundung notgedrungen äusserst vage ist.
vorsicht.
dieser thread behandelt ein problem, das sich auf die timerzeiten eines registers in der statemachine bezieht.
hier ist es ein 8bit/1byte wert.
für die einstellung des befehls on-for-timer wird ein 16bit/2byte wert genutzt.
die im wiki aufgeführte funktion CUL_HM_encodeTime16($) hat nichts mit der dortigen beschreibung zu tun, sondern ist nur für den on-for-timer fall.
ACK. Ich hatte noch gar nicht draufschauen können. Wir müssen das trennen.
Ja, inzwischen auch kapiert.
Dann werde ich das aber erstmal wieder wegwerfen...