Moin Martin,
so, ich wollte das Thema mit meinem mechanischen Display noch mal aufgreifen, weil ich im alten Jahr nicht mehr dazu gekommen bin.
Problem: Alle Kommandos vom Display (On|Off) kommen prima in fhem an. Nur auf ein Kommando von fhem Richtung Display bekomme ich in 99% der Fälle ein Missing ACK
Anbei mal der Mitschnitt, wo ich versucht habe das Display zu schalten.
Kannst du da was erkennen?
2013.01.16 11:04:44 2: CUL_HM set Casa_Alarm_Display off rxt:2
2013.01.16 11:04:54 2: CUL_HM set Casa_Alarm_Display on rxt:2
2013.01.16 11:04:55 2: CUL_HM set Casa_Alarm_Display off rxt:2
2013.01.16 11:21:00.012 1: SW: ORb
2013.01.16 11:21:00.028 1: SW: Om6700000002D1113A
2013.01.16 11:21:00.056 1: SW: OwBf5
2013.01.16 11:21:00.068 1: SW: OrB
2013.01.16 11:21:00.080 1: SW: OrB
2013.01.16 11:21:00.091 1: SW: ORb
2013.01.16 11:21:30.003 1: SW: ORb
2013.01.16 11:21:30.015 1: SW: Om6700000002D1113A
2013.01.16 11:21:30.042 1: SW: OwBf5
2013.01.16 11:21:30.054 1: SW: OrB
2013.01.16 11:21:30.066 1: SW: OrB
2013.01.16 11:21:30.078 1: SW: ORb
2013.01.16 11:23:43.216 1: CUNO_2: A0CF3867019DF1F00000000B12D -57
2013.01.16 11:23:43.288 1: SW: ORb
2013.01.16 11:23:43.300 1: SW: OmEE0008025743CD10
2013.01.16 11:23:43.328 1: SW: OwBbe
2013.01.16 11:23:43.340 1: SW: OrB
2013.01.16 11:23:43.352 1: SW: OrB
2013.01.16 11:23:43.364 1: SW: OrB
2013.01.16 11:23:43.375 1: SW: OrB
2013.01.16 11:23:43.387 1: SW: OrB
2013.01.16 11:23:43.399 1: SW: OrB
2013.01.16 11:23:43.411 1: SW: OrB
2013.01.16 11:23:43.423 1: SW: OrB
2013.01.16 11:23:43.435 1: SW: OrB
2013.01.16 11:23:49.837 1: CUNO_2: A0C95867019E2C800000000B428 -51.5
2013.01.16 11:23:52.562 1: CUNO_2: A0D13A4101B1119F100000601C800 -41
2013.01.16 11:23:52.666 1: SW: As0A138002F100001B111900
2013.01.16 11:23:57.582 1: SW: As0E14B011F100001B11190201000000
2013.01.16 11:23:58.020 1: CUNO_2: A0BF3A25819DF1F19DB980032 -57
2013.01.16 11:23:58.267 1: CUNO_2: A0EF3820219DB9819DF1F0101260031 -64.5
2013.01.16 11:23:59.598 1: SW: As0E14B011F100001B11190201000000
2013.01.16 11:24:00.000 1: SW: ORb
2013.01.16 11:24:00.012 1: SW: Om6700000002D1113A
2013.01.16 11:24:00.040 1: SW: OwBf5
2013.01.16 11:24:00.052 1: SW: OrB
2013.01.16 11:24:00.064 1: SW: OrB
2013.01.16 11:24:00.076 1: SW: ORb
2013.01.16 11:24:00.140 1: SW: ORb
2013.01.16 11:24:00.156 1: SW: Om66000802573F1D10
2013.01.16 11:24:00.184 1: SW: OwBbe
2013.01.16 11:24:00.196 1: SW: OrB
2013.01.16 11:24:00.207 1: SW: OrB
2013.01.16 11:24:00.219 1: SW: OrB
2013.01.16 11:24:00.231 1: SW: OrB
2013.01.16 11:24:00.243 1: SW: OrB
2013.01.16 11:24:00.255 1: SW: OrB
2013.01.16 11:24:00.267 1: SW: OrB
2013.01.16 11:24:00.279 1: SW: OrB
2013.01.16 11:24:00.291 1: SW: OrB
2013.01.16 11:24:00.646 1: SW: As0E14B011F100001B11190201000000
2013.01.16 11:24:01.000 1: SW: ORb
2013.01.16 11:24:01.012 1: SW: Om7E00080257304E10
2013.01.16 11:24:01.040 1: SW: OwBbe
2013.01.16 11:24:01.052 1: SW: OrB
2013.01.16 11:24:01.064 1: SW: OrB
2013.01.16 11:24:01.076 1: SW: OrB
2013.01.16 11:24:01.088 1: SW: OrB
2013.01.16 11:24:01.100 1: SW: OrB
2013.01.16 11:24:01.112 1: SW: OrB
2013.01.16 11:24:01.124 1: SW: OrB
2013.01.16 11:24:01.136 1: SW: OrB
2013.01.16 11:24:01.148 1: SW: OrB
2013.01.16 11:24:01.215 1: SW: ORb
2013.01.16 11:24:01.231 1: SW: OmA00008025740CD10
2013.01.16 11:24:01.259 1: SW: OwBbe
2013.01.16 11:24:01.271 1: SW: OrB
2013.01.16 11:24:01.283 1: SW: OrB
2013.01.16 11:24:01.295 1: SW: OrB
2013.01.16 11:24:01.355 1: SW: OrB
2013.01.16 11:24:01.407 1: SW: OrB
2013.01.16 11:24:01.419 1: SW: OrB
2013.01.16 11:24:01.431 1: SW: OrB
2013.01.16 11:24:01.442 1: SW: OrB
2013.01.16 11:24:01.454 1: SW: OrB
2013.01.16 11:24:01.518 1: SW: ORb
2013.01.16 11:24:01.530 1: SW: Om5D00000002C9BE3A
2013.01.16 11:24:01.558 1: SW: OwBf5
2013.01.16 11:24:01.570 1: SW: OrB
2013.01.16 11:24:01.582 1: SW: OrB
2013.01.16 11:24:01.594 1: SW: ORb
2013.01.16 11:24:01.642 1: SW: ORb
2013.01.16 11:24:01.654 1: SW: OmD500080254A98510
2013.01.16 11:24:01.682 1: SW: OwBbe
2013.01.16 11:24:01.693 1: SW: OrB
2013.01.16 11:24:01.705 1: SW: OrB
2013.01.16 11:24:01.717 1: SW: OrB
2013.01.16 11:24:01.729 1: SW: OrB
2013.01.16 11:24:01.741 1: SW: OrB
2013.01.16 11:24:01.753 1: SW: OrB
2013.01.16 11:24:01.765 1: SW: OrB
2013.01.16 11:24:01.777 1: SW: OrB
2013.01.16 11:24:01.789 1: SW: OrB
2013.01.16 11:24:04.713 1: SW: As0E15B011F100001B11190201C80000
2013.01.16 11:24:06.729 1: SW: As0E15B011F100001B11190201C80000
2013.01.16 11:24:07.753 1: SW: As0E15B011F100001B11190201C80000
2013.01.16 11:24:09.924 1: CUNO_2: A0B95A25819E2C819DDFA005D -51
2013.01.16 11:24:10.171 1: CUNO_2: A0E95820219DDFA19E2C80101480034 -51.5
2013.01.16 11:24:14.884 1: CUNO_2: A0C79867019E3D600000000B12E -63
2013.01.16 11:24:17.613 1: CUNO_2: A0C19867019E4F4000000004841 -73
Hi Dougie
Genau genommen sehen ich garkeine Antwort auf Kommandos der Zentrale.
evtl kannst du einmal ein getConfig aufzeichnen - mal sehen, ob wir ueberhaupt mit dem Device reden koennen
Gruss
Martin
...danke Martin, ich hab mal ein getConfig probiert.
Das hier stand im Log... hab es hoffentlich richtig gemacht?
013.01.16 13:48:08.009 1: SW: ORb
2013.01.16 13:48:08.025 1: SW: Om6700000002D1113A
2013.01.16 13:48:08.053 1: SW: OwBf5
2013.01.16 13:48:08.065 1: SW: OrB
2013.01.16 13:48:08.077 1: SW: OrB
2013.01.16 13:48:08.089 1: SW: ORb
2013.01.16 13:48:27.714 1: CUNO_2: A0C52867019E4F4000000004841 -72.5
2013.01.16 13:48:32.176 1: CUNO_2: A0B2CA25819DF1F19DB980036 -57
2013.01.16 13:48:32.495 1: CUNO_2: A0E2C820219DB9819DF1F01012A0032 -62
2013.01.16 13:48:34.004 1: SW: ORb
2013.01.16 13:48:47.072 1: SW: Om7E00080257304E10
2013.01.16 13:48:47.099 1: SW: OwBbe
2013.01.16 13:48:47.111 1: SW: OrB
2013.01.16 13:48:47.123 1: SW: OrB
2013.01.16 13:48:47.135 1: SW: OrB
2013.01.16 13:48:47.147 1: SW: OrB
2013.01.16 13:48:47.159 1: SW: OrB
2013.01.16 13:48:47.171 1: SW: OrB
2013.01.16 13:48:47.183 1: SW: OrB
2013.01.16 13:48:47.195 1: SW: OrB
2013.01.16 13:48:47.207 1: SW: OrB
2013.01.16 13:48:47.275 1: CUNO_2: A0BCEA25819E2C819DDFA008B -51.5
2013.01.16 13:48:47.335 1: CUNO_2: A0ECE820219DDFA19E2C801016C0033 -52
2013.01.16 13:48:47.414 1: CUNO_2: A0C79867019E41900000000C028 -75
2013.01.16 13:48:47.510 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:48:47.530 1: SW: ORb
2013.01.16 13:48:47.542 1: SW: OmD500080254A98510
2013.01.16 13:48:47.578 1: SW: OwBbe
2013.01.16 13:48:47.589 1: SW: OrB
2013.01.16 13:48:47.601 1: SW: OrB
2013.01.16 13:48:47.613 1: SW: OrB
2013.01.16 13:48:47.625 1: SW: OrB
2013.01.16 13:48:47.637 1: SW: OrB
2013.01.16 13:48:47.649 1: SW: OrB
2013.01.16 13:48:47.661 1: SW: OrB
2013.01.16 13:48:47.673 1: SW: OrB
2013.01.16 13:48:47.685 1: SW: OrB
2013.01.16 13:48:47.697 1: OWX: Received unexpected number of 39 bytes from CUNO/COC
2013.01.16 13:48:47.697 1: SW: ORb
2013.01.16 13:48:47.709 1: SW: OmD500080254A98510
2013.01.16 13:48:47.737 1: SW: OwBbe
2013.01.16 13:48:47.749 1: SW: OrB
2013.01.16 13:48:47.761 1: SW: OrB
2013.01.16 13:48:47.773 1: SW: OrB
2013.01.16 13:48:47.785 1: SW: OrB
2013.01.16 13:48:47.797 1: SW: OrB
2013.01.16 13:48:47.809 1: SW: OrB
2013.01.16 13:48:47.821 1: SW: OrB
2013.01.16 13:48:47.833 1: SW: OrB
2013.01.16 13:48:47.844 1: SW: OrB
2013.01.16 13:48:47.908 1: SW: ORb
2013.01.16 13:48:47.924 1: SW: OmA00008025740CD10
2013.01.16 13:48:47.952 1: SW: OwBbe
2013.01.16 13:48:47.964 1: SW: OrB
2013.01.16 13:48:47.976 1: SW: OrB
2013.01.16 13:48:47.988 1: SW: OrB
2013.01.16 13:48:48.000 1: SW: OrB
2013.01.16 13:48:48.012 1: SW: OrB
2013.01.16 13:48:48.024 1: SW: OrB
2013.01.16 13:48:48.036 1: SW: OrB
2013.01.16 13:48:48.048 1: SW: OrB
2013.01.16 13:48:48.060 1: SW: OrB
2013.01.16 13:48:48.123 1: SW: ORb
2013.01.16 13:48:48.139 1: SW: Om5D00000002C9BE3A
2013.01.16 13:48:48.167 1: SW: OwBf5
2013.01.16 13:48:48.179 1: SW: OrB
2013.01.16 13:48:48.191 1: SW: OrB
2013.01.16 13:48:48.203 1: SW: ORb
2013.01.16 13:48:48.255 1: SW: ORb
2013.01.16 13:48:48.267 1: SW: Om6700000002D1113A
2013.01.16 13:48:48.295 1: SW: OwBf5
2013.01.16 13:48:48.307 1: SW: OrB
2013.01.16 13:48:48.319 1: SW: OrB
2013.01.16 13:48:48.331 1: SW: ORb
2013.01.16 13:48:49.681 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:48:52.605 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:48:55.741 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:48:57.003 1: SW: ORb
2013.01.16 13:48:57.019 1: SW: OmEE0008025743CD10
2013.01.16 13:48:57.047 1: SW: OwBbe
2013.01.16 13:48:57.059 1: SW: OrB
2013.01.16 13:48:57.071 1: SW: OrB
2013.01.16 13:48:57.083 1: SW: OrB
2013.01.16 13:48:57.095 1: SW: OrB
2013.01.16 13:48:57.107 1: SW: OrB
2013.01.16 13:48:57.119 1: SW: OrB
2013.01.16 13:48:57.131 1: SW: OrB
2013.01.16 13:48:57.143 1: SW: OrB
2013.01.16 13:48:57.155 1: SW: OrB
2013.01.16 13:48:57.219 1: SW: ORb
2013.01.16 13:48:57.231 1: SW: OmD2000802573A5310
2013.01.16 13:48:57.258 1: SW: OwBbe
2013.01.16 13:48:57.270 1: SW: OrB
2013.01.16 13:48:57.282 1: SW: OrB
2013.01.16 13:48:57.294 1: SW: OrB
2013.01.16 13:48:57.310 1: SW: OrB
2013.01.16 13:48:57.322 1: SW: OrB
2013.01.16 13:48:57.334 1: SW: OrB
2013.01.16 13:48:57.346 1: SW: OrB
2013.01.16 13:48:57.358 1: SW: OrB
2013.01.16 13:48:57.370 1: SW: OrB
2013.01.16 13:48:57.474 1: CUNO_2: A0C0486701938BE00000000D02A -45
2013.01.16 13:48:57.840 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:49:01.430 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:49:02.931 1: CUNO_2: A0B79A25819E41919D9130036 -75
2013.01.16 13:49:02.999 1: CUNO_2: A0E79820219D91319E41901012A003C -58.5
2013.01.16 13:49:03.684 1: SW: As10C4B001F100001B111900040000000000
2013.01.16 13:49:07.146 1: CUNO_2: A0B83A2581B18F419DB870044 -70
2013.01.16 13:49:07.393 1: CUNO_2: A0E83820219DB871B18F40101360028 -64.5
2013.01.16 13:49:07.477 1: CUNO_2: A0CB2867019E3D600000000B32D -64
2013.01.16 13:49:07.648 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:10.134 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:14.142 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:17.066 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:17.560 1: CUNO_2: A0B04A2581938BE193A800016 -45
2013.01.16 13:49:17.632 1: CUNO_2: A0E048202193A801938BE010114003B -45.5
2013.01.16 13:49:18.003 1: SW: ORb
2013.01.16 13:49:18.015 1: SW: Om6700000002D1113A
2013.01.16 13:49:18.042 1: SW: OwBf5
2013.01.16 13:49:18.054 1: SW: OrB
2013.01.16 13:49:18.066 1: SW: OrB
2013.01.16 13:49:18.078 1: SW: ORb
2013.01.16 13:49:19.791 1: CUNO_2: A0C01867019E56B00000000B42F -65.5
2013.01.16 13:49:19.971 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:23.943 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:26.672 1: SW: As0BC5B001F100001B11190103
2013.01.16 13:49:27.480 1: CUNO_2: A0BB2A25819E3D61888B2002D -63.5
2013.01.16 13:49:27.536 1: CUNO_2: A0EB282021888B219E3D60101240041 -64
2013.01.16 13:49:31.982 1: CUNO_2: A0C9586701B18B400000000C42C -65
2013.01.16 13:49:39.137 1: CUNO_2: A0C5C867019E24F000000009539 -75
2013.01.16 13:49:39.631 1: CUNO_2: A0B01A25819E56B19DB730052 -65.5
2013.01.16 13:49:39.882 1: CUNO_2: A0E01820219DB7319E56B010142002D -52.5
...so sieht das Device aus...
(siehe Anhang / see attachement)
Hallo Dougie,
das sieht einfach schlecht aus. Der 1B1119 reagiert einfach garnicht. Da kann ich nichts machen.
Habe ich etwas uebersehen? Hat er schon einmal auf irgend etwas reagiert?
Es sieht schon etwas nach HW-fehler aus
Gruss
Martin
Moin Martin,
also was geht, ist das Display mit fhem zu pairen. Das ist immer erfolgreich. Es ist halt auch schon mal vereinzelt vorgekommen, das das Display auf ein Kommando reagiert hat. Die Erfolgsrate liegt aber bei ca. 2%
Ich bin da leider ratlos.
VG
Ralf
Ralf,
das Device braucht einen 'burst-event' zum Aufwachen. wenn man sendet solange das Device aktiv ist, koennte es funktionieren. Fuer einen regelmaessigen Betrieb ist dies nicht hinreichend.
Was nicht funktionieren kann ist, dass man autonom eine message an das Device schickt. Damit ist die Sache geklaert - denn fuer dieses Device ist es unabdingbar autonome messages zu schicken - richtig?
Das ganze funktioniert reibungslos mit einem HMLAN. Dieser schaltet den burst-event automatisch wenn ich ein bestimmtes Bit schicke. Die CUL schickt nie einen burst-event.
Was notwendig ist, ist einzubauen, eine CUL einen burst-event schicken zu lassen. Der Rest waere wieder einfach.
Gruss
Martin
Danke Martin,
ja, das Display ist natürlich als Zustandsanzeige zwingend darauf angewiesen, jederzeit erreichbar zu sein.
Ich hoffe ich hab deine Erklärung richtig verstanden, dann wäre das etwas, was in culfw implementiert werden müsste.
Tja, ich hab hier noch einen HM-LAN Adapter liegen, aber den noch nie verwendet. Ich bin hin und her gerissen zu warten, ob so ein Burst mal programmiert wird, oder HM-Lan zu verwenden...
Schiewerig.
VG
Ralf
Wenn du eh einen HM-Lan da liegen hast währ das für die HomeMatic Komponenten von Vorteil.
HM-Lan wiederholt die Befehle bei kurzeitigen Funkstörungen nämlich auch selbstständig.
Oder hattest du das Bei CUL_HM mitterweile auch implementiert Martin?
Sofern ist die Funkverbindung dadurch etwas sicherer gestellt.
Du Kannst CUL und HM-Lan aber auch parallel benutzen.
Gruß
Dirk
Danke für den Tipp, Dirk!
Aktuell verwende ich (noch) CUL und CUNO an der FritzBox, aber beim anstehenden Umzug auf den RPi werde ich das wohl mal probieren. Ich wollte aber nur zwei Funk-Schnittstellen verwenden. Eine für FS20 und eine für HM.
Dann wird's wohl der HM-LAN werden....
VG
Ralf
Ich habe das mal eben umgesetzt und in meine Test-Installation zusätzlich den HM-LAN Adapter integriert.
Und ihr habt natürlich recht: mit dem HM-LAN funktioniert das Steuern des Displays einwandfrei. Das bedeutet, das ich demnächst mit der ganzen Konfiguration umziehen muss. Das wird ne grössere Nummer. ;-)
Vielen Dank für eure Tipps & Hilfe!
VG
Ralf
@dirk - schnelle wiederholer sind nur in HMLAN -HW vorhanden. Wenn, dann baue ich es in CUL ein, nicht in CUL_HM - das waere eh etwas zu langsam - und nicht symetrisch
Ist nicht ganz trivial, da somit eine relativ komplexe stack-verwaltung in CUL fuer HM eingebaut werden muesste - mal sehen.
@Ralf - ich bin nicht informiert, dass jemand aktiv am Problem "burst fuer CUL" arbeitet. Somit koennte die Wartezeit etwas laenger sein.
Aus Interesse - warum ist das umziehen von CUL nach HMLAN eine grosse sache? wenn du deine CUL ausschaltest und dem HMLAN die HMID der vormals CUL gibst sollte es alles funktionieren.
Es ist darauf zu achten, dass HMLAN im fhem-config file vor den devices angelegt wird. Ich kann somit ohne probleme umschalten. HM-devices wissen nicht, on das IO ueber CUL oder HMLAN geht.
Gruss
Martin
Zitat von: martinp876 schrieb am Fr, 18 Januar 2013 09:30Aus Interesse - warum ist das umziehen von CUL nach HMLAN eine grosse sache? wenn du deine CUL ausschaltest und dem HMLAN die HMID der vormals CUL gibst sollte es alles funktionieren.
Es ist darauf zu achten, dass HMLAN im fhem-config file vor den devices angelegt wird. Ich kann somit ohne probleme umschalten. HM-devices wissen nicht, on das IO ueber CUL oder HMLAN geht.
Gruss
Martin
Martin,
so sieht meine aktuelle config aus.
define CUNO_2 CUL 192.168.1.15:2323 0000
attr CUNO_2 model CUN
attr CUNO_2 rfmode HomeMatic
attr CUNO_2 room 10_System
attr CUNO_2 sendpool CUL_0,CUNO_1,CUNO_2Wenn ich es richtig verstanden habe, muss ich mit dem HM-LAN eine ID verwenden die von "0000" verschieden ist, oder macht er da HM0000 draus und macht einfach weiter?
Des weiteren war ich bislang der Auffassung, das das Pairing mehr als nur die HM-ID umfassen würde, und daher ein erneutes Anlernen nötig werden würde. Wenn dem nicht so ist: umso besser! :-) Habe gerade den entsprechenden Thread gefunden und gelesen.
Hier stünden ansonsten 11 HM-CC-TC, 12 -VD und ne handvoll Kleinkram zum neu Programmieren an....
VG
Ralf
Sorry... die HMid würde dann zu F10000 .... mal eben nachgelesen.
VG
Ralf
F10000 kann sein - eben das, was du auch aus den pairings der devices auslesen kannst.
Anmerkungen:
HM0000 geht garnicht. Die HMID ist ein 3 Byte Wert in HEX Darstellung - es ist KEIN ASCII string!. Also nie Buchstaben groesser F angeben, und immer 6 Zeichen.
Ich habe nie gesehen, dass beim pairing etwas anderes eingestellt wird als die HMID. Das Protokoll ist einfacher als die meisten denken...
Wie gesagt, ich habe oft zwischen HLMAN und CUL umgeschaltet, keine Probleme bei mir.
VG
Martin
F10000 hat wunderbar funktioniert! Hab inzwischen meine Konfig auf den HMLAN umgestellt und es läuft!!
Endlich habe ich eine Anzeige an der Haustüre, ob die Alarmanlage scharf oder unscharf ist. Grosse Freude herrscht!
VG
Ralf
Zitat von: martinp876 schrieb am Fr, 18 Januar 2013 12:21F10000 kann sein - eben das, was du auch aus den pairings der devices auslesen kannst.
Anmerkungen:
HM0000 geht garnicht. Die HMID ist ein 3 Byte Wert in HEX Darstellung - es ist KEIN ASCII string!. Also nie Buchstaben groesser F angeben, und immer 6 Zeichen.
Ich habe nie gesehen, dass beim pairing etwas anderes eingestellt wird als die HMID. Das Protokoll ist einfacher als die meisten denken...
Wie gesagt, ich habe oft zwischen HLMAN und CUL umgeschaltet, keine Probleme bei mir.
VG
Martin
Hi zusammen,
ich greife dieses alte Thema nochmal auf.
ZitatProblem: Alle Kommandos vom Display (On|Off) kommen prima in fhem an. Nur auf ein Kommando von fhem Richtung Display bekomme ich in 99% der Fälle ein Missing ACK
Die Lösung war ein HMLAN, was ich nicht habe. Im fhemwiki ist als Voraussetzung für die Nutzung mit dem CUL die Firmware culfw >= 1.55 genannt, die den Burst Modus unterstützt:
ZitatDa die Retroanzeige den sogenannten Burstmodus benutzt, muss ein CUL oder CUNO mindestens mit culfw 1.55 Firmware geflascht sein. Ältere culfw unterstützen Burst nicht.
Muss ich den Burst-Modus extra einschalten (wie/wo?):
Aktuell ist Firmware 1.66 auf einem CUL von Busware geflasht, ich hatte angenommen, dass es mit dieser Firmware "automatisch" funktioniert.
CUL1 version => V 1.66 CUL868Bei mir kommt aus Richtung fhem nichts beim HM-Dis-TD-T an:
Ein "get config" bekommt
RESPONSE TIMEOUT:RegisterReadein "set FLU_Alarm_Schalter on"
MISSING ACKIch nehme an, dass irgendwas gesetzt werden muss, damit dieser burst Modus genutzt wird. Kann mich bitte jemand in die richtige Richtung schubsen? Ich war doch schon so stolz das Ding zusammengelötet zu haben... und nun das :-(
LG Sille
ach mal ein
list FLU_Alarm_Schalter
und poste den hier
burst muß man nicht extra setzten
Hi,
ein "list FLU_Alarm_Schalter" liefert:
Internals:
CUL1_MSGCNT 6
CUL1_RAWMSG A0D348410385B3100000006010000::-41.5:CUL1
CUL1_RSSI -41.5
CUL1_TIME 2016-02-27 19:46:45
DEF 385B31
IODev CUL1
LASTInputDev CUL1
MSGCNT 6
NAME FLU_Alarm_Schalter
NR 525
NTFY_ORDER 50-FLU_Alarm_Schalter
STATE off
TYPE CUL_HM
lastMsg No:34 - t:10 s:385B31 d:000000 06010000
protCmdDel 5
protLastRcv 2016-02-27 19:46:45
protResnd 4 last_at:2016-02-27 18:35:46
protResndFail 4 last_at:2016-02-27 18:35:50
protSnd 4 last_at:2016-02-27 18:35:43
protState CMDs_done_Errors:1
rssi_at_CUL1 avg:-49.16 min:-53.5 max:-41.5 lst:-41.5 cnt:6
Readings:
2016-02-27 15:53:17 D-firmware 1.1
2016-02-27 15:53:17 D-serialNr xxxxxxxxxx
2016-02-27 17:31:26 RegL_00.
2016-02-27 19:46:45 deviceMsg off (to broadcast)
2016-02-27 19:46:45 level 0
2016-02-27 18:44:29 levelMissed desired:100
2016-02-27 19:46:45 pct 0
2016-02-27 19:46:45 recentStateType info
2016-02-27 19:46:45 state off
2016-02-27 19:46:45 timedOn off
Helper:
HM_CMDNR 52
cSnd 11F12503385B310201C80000,11F12503385B310201C80000
getCfgList all
getCfgListNo ,3
mId 0078
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +385B31,00,00,00
nextSend 1456598805.70347
prefIO
rxt 0
vccu
p:
385B31
00
00
00
Mrssi:
mNo 34
Io:
CUL1 -39.5
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
At_cul1:
avg -49.1666666666667
cnt 6
lst -41.5
max -41.5
min -53.5
Attributes:
IODev CUL1
alarmDevice Actor
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
group Alarmanlage
model HM-Dis-TD-T
msgRepeat 1
room CUL_HM,Flur.unten
serialNr xxxxxxxxxx
subType switch
webCmd statusRequest:toggle:on:off
LG Sille
da fehlen die Pairing Readings, senden tut er auch nach Broadcast
s:385B31 d:000000 06010000
nochmal richtig pairen
Hi,
warum auch immer - nach dreimaligem Rücksetzen auf Werkseinstellungen samt Pairing - nun funktioniert es.
Leider kann ich nicht nachvollziehen, was beim Letzten Pairing anders gelaufen ist und somit Mitlesern keine Erkenntnisse mitteilen.
Vielen Dank für die Unterstützung
LG Sille