HomeMatic 16 LED Display HM-OU-LED16

[dou...@gmx.de]

...aus einem Spieltrieb heraus hab ich mir so ein 16 LED HM Display Bausatz gekauft. Ist ja schnell zusammen gebaut. 

Hab das Ding eben mit fhem gepairt

2012.09.27 15:27:43 2: CUL_HM pair: Display_16LED subType unknown, model unknown serialNr JEQ0144304

Aber hier hab ich noch nichts genaues gefunden, wie ich das Ding als fhem Display verwende.

Ich hatte mir auch vor ein paar Wochen mal einen HM-LAN Adapter gekauft, aber der liegt noch verpackt in der Ecke.

Wenn es die Info noch nicht geben sollte, und mich mal jemand kurz auf die Spur setzt, wie ich das mit LAN-Adapter und fhem analysiert bekomme, würde ich gerne die fehlende Info beisteuern.

VG
Ralf

[thot...@gmx.net]

Hallo,

ich habe auch schon mal mit dem Gedanken gespielt, mir so ein Teil zu kaufen.

Da es aber in fhem noch nicht "aufgetaucht" ist und ich relativ wenig Zeit habe, habe ich es dann doch sein lassen.

Aber an anderer Stelle habe ich evtl. hilfreiche Informationen gefunden, wie die Farbwerte der LED's "erzeugt" werden.

 

Evtl. hilfreich für weitere Analysen??

VG

[dou...@gmx.de]

Ja, klar! Hilft bestimmt alles.

Ich hatte ansonsten die Idee, den HM-LAN Adapter dazu zu verwenden, das er das Display ansteuert,und fhem mitlauschen zu lassen, was die beiden so austauschen. Hoffe das war nicht zu naiv gedacht? :-)

VG
Ralf

[thot...@gmx.net]

Hi,

ich denke mal das ist nicht zu naiv gedacht.

Das habe ich bei ähnlicher Gelegenheit auch schon gemacht.

Über die Windows hm-lan-cfg Software die Geräte konfiguriert und fhem lauschen lassen.

Auch im Bereich Rauchmelder ist das so ähnlich gelaufen (Alarm und Netzwerktest), woraufhin Rudolf König das netterweise in fhem mit aufgenommen hat.

Die Exceltabelle hilft ja evtl., nicht alles neu erfinden zu müssen.

 

Viel Erfolg und VG

[fhem-hm-knecht]

fhem mitlauschen zu lassen:) genau so

HM-OU-LED16, genauso das Display von der großen 19TFernbedienung
sind bereits bekannt,
mußt eben noch eine Weile warten :)
bis zu veröffentlichung.

Hary

[dou...@gmx.de]

Alles schon bekannt?? Eigentlich ja prima, aber ich hatte gehofft endlich mal was beitragen zu können :-)

Senden kann der Bilderrahmen jedenfalls schon ;-)

2012-09-27 17:39:07 CUL_HM Display_16LED unknownMsg: (A440) 0102

2012-09-27 17:39:08 CUL_HM Display_16LED unknownMsg: (A040) 0102

2012-09-27 17:39:08 CUL_HM Display_16LED unknownMsg: (A040) 0102

Wo wird das dann drin sein? In der CUL_HM?

VG
Ralf

[Rudolf Koenig]

> Wo wird das dann drin sein? In der CUL_HM?

Ja, in der Version von Martin, der es nach eigenen Angaben demnaechst auch ins
SVN einchecken will. Siehe auch div. andere Diskussionen darueber hier in der
Gruppe.

[dou...@gmx.de]

..ich konnte es ja nicht lassen und hab schon mal gestöbert. :-)

Hab mir die CUL_HM von Martin vom 21. September runter geladen und teste die gerade. :-)

mit 

set Display_16LED led red

gehen wie erwartet alle LEDs auf rot (usw.) und Tastendrücke am Display werden schon mit ACK quittiert ... saucool!

Leider hab ich noch ein Verständnisproblem, wie ich einzelne Channels setzen kann. Ich hab mir zwei Channels definiert, aber ich hab nirgends die Syntax gefunden, wie ich z.B, Channel 2 rot setzen kann.

Oder ist das noch nicht implementiert?  :-)

Bemerkenswerte Arbeit, Martin!!

VG
Ralf

define Display_16LED CUL_HM 1AC64D

attr Display_16LED channel_01 DispLed1

attr Display_16LED channel_02 DLED2

attr Display_16LED devInfo 100000

attr Display_16LED firmware 1.1

attr Display_16LED hmClass unknown

attr Display_16LED model HM-OU-LED16

attr Display_16LED protLastRcv 2012-09-27 19:42:39

attr Display_16LED protSndCnt 6

attr Display_16LED protSndLast 2012-09-27 19:37:26

attr Display_16LED serialNr JEQ0144304

attr Display_16LED subType outputUnit

[Martin]

Die Syntax ist wie folgt eingebaut

OutputUnit (HM-OU-LED16)

• led [off|red|green|yellow]
  switches the LED of the channel to the color. If the command is executed on a device it will set all LEDs to the specified color
  
• ilum [0-15] [0-127]
  set the backlight ilumination of the device to a level between 0 and 15 an on-duration to up to 127 sec

Das Geraet hat 16 Kanaele - du musst also fuer jede LED einen Kanal definieren (so hat es HM aufgebaut). In der Version neusten Version werden die 16 Kanaele automatisch generiert wenn eine device_Info empfangen wird (z.B. durch druecken der Anlerntaste). Passiert uebrigens auch wenn das Device schon da ist. Natuerlich werden bestehende Kanaele nicht ueberschrieben.

Default Name de Kanaele ist <devicename>_LED_01 bis_LED_0F und _LED_10 

Besonderheit ist, dass alle LEDs auf einmal gesetzt (oder geloescht) werden koennen wenn als entity das Device angegeben wird. Bei Ilum ist natuerlich das Device anzugeben.

Was noch fehlt ist der Sleepmode. Hatten wir noch nicht getestet - falls der dich also interresseirt...
muesste funktionieren mit

raw ++A011<src><dst>820001 # sleep mode on
raw ++A011<src><dst>820000 # sleep mode off

oder falls es mit Kanal geht:
raw ++A011<src><dst>820101 # sleep mode on
raw ++A011<src><dst>820100 # sleep mode off

Dann waere noch ein Kommando erforderlich

Gruss

Martin

[dou...@gmx.de]

Danke Martin, 

ich hatte gestern wohl einen Hänger...

mit 

set DLED2 led red 

funktioniert es einwandfrei! Erste Sahne!

Wo veröffentlichst du denn die jeweils aktuelle Version?

Ich hab übrigens 

set CUNO_2 raw ++A011F100001AC64D820000 

probiert, um den Sleep Mode aus zu schalten (Dauerhafte Anzeige).  Aber das klappt bei mir nicht. LEDs gehen nach ner Weile aus.

VG
Ralf

[dou...@gmx.de]

Nachtrag: 

Darf ich mal eben kund tun, das dieses 16 LED Display (in Wirklichkeit sind ja 48 Zustände darstellbar) imho echt super ist? 

Dazu kommt noch, das es eine 16 Kanal Fernbedienung obendrein gibt. 

Bin total begeistert! Immer den Zustand der wesentlichen Dinge im Auge, ohne einen PC hoch fahren zu müssen, und ich denke auch als Alarmanzeige auf dem Nachttisch denkbar.

Nochmal danke dafür, Martin! :-)

VG
Ralf

[Martin]

funktioniert es einwandfrei! Erste Sahne!

Wo veröffentlichst du denn die jeweils aktuelle Version?

habe angekuendigt es zu beginn der naechsten Woche in SVN zu stellen. Bisher nur an einige Tester und bei hilfestellungen im Forum. Aber es soll ja keine parallel Entwicklung sein. Ich will am Wochenende noch ein bischen probieren - die Codeaenderungen sind mittlerweile doch erheblich .. und in SVN bekommen es alle um die Ohren...
Ich versuche wenigstens vorsichtig zu sein... aber ein paar bug habe ich zum suchen sicher noch drin :-)

set CUNO_2 raw ++A011F100001AC64D820000 

a) ich weiss nicht, was der sleepmode macht - soll er verhindern, dass das device die Beleuchtung ausschaltet oder erreichen, dass es in der Nacht dunkel wird?
b) hast du ein ack bekommen?
c) schicke es doch mal an kanal 01
d) probier mal sleepmode ein - bleibt es dann dunkel?
e) hast du schon mit ilum gespielt? was passiert bei dauer 0? garnicht oder immer an?

[dou...@gmx.de]

Moin Martin,

alles konnte ich gestern nicht mehr testen.

Was ich sagen kann, ist das der ilum Befehl grundsätzlich prima funktioiniert. 

 if (isday()) {

   fhem ("set Display_16LED ilum 15 127")

   } else {

   fhem ("set Display_16LED ilum 2 20")

   };

So ist es in der Nacht auf den Nachttisch nicht nervig und man hat dennoch alles im Blick.

Um das Testen der restlichen Daten versuche ich mich heute zu kümmern.

VG
Ralf

[dou...@gmx.de]

 

Einen schönen Sonntag zusammen,

hatte gestern schon wieder keine Zeit und konnte nur rudimentär testen. Dennoch etwas Feedback:

Der ilum Befehl lässt sich nur auf das Device anwenden, nicht aber auf einen Kanal. 

Der Timer-Wert 0 schaltet das Display dauerhaft ein

Z.B. set Display_16LED ilum 15 0

bedeutet volle Helligkeit, dauerhaft an.

In der Nacht schalte ich um auf

set Display_16LED ilum 1 15

bedeutet: so dunkel wie geht, für 15 Sekunden. 

Da sich aber mit dem ilum Befehl allein schon das Display prima steuern lässt, hab ich da erst mal nicht weiter gemacht. 

Was mit noch aufgefallen ist: verwende ich das Display als Fernsteuerung, werden die Kommandos zwischen zwei und drei mal gesendet, und ein positives ACK (LED am Display wird kurz grün) kommt in (nur) ca. 75% der Fälle.

Auszug aus dem Event-Log ein Beispiel für einen einmaligen Testendruck

2012-09-30 09:23:02 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-09-30 09:23:02 CUL_HM Display_16LED Btn16: on (to CUNO_2)

2012-09-30 09:23:02 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-09-30 09:23:02 CUL_HM Display_16LED Btn16: on (to CUNO_2)

Ich hab mir ein notify gebastelt, welches den Button und den Status an ein Programm in der 99_MyUtils übergibt.

Auszug aus der fhem.cfg

Display_16LED.Btn:.* {

prg_DispLed16_notify("%EVTPART0","%EVTPART1")

}

Auszug aus der 99_MyUtils

sub

prg_DispLed16_notify($$) 

{

 my($BtnNr,$Stat) = @_;

 $BtnNr=(substr($BtnNr, 3, (length($BtnNr)-3)));

 Log 3,"Button: $BtnNr - Status: $Stat";

}

Da der Befehl vom Display mehrfach gesendet wird, kann ich kein einfaches togglen von Aktoren machen.

Macht die Fernbedienung das auch?

[Rudolf Koenig]

> Da der Befehl vom Display mehrfach gesendet wird, kann ich kein einfaches
> togglen von Aktoren machen.
> Macht die Fernbedienung das auch?

Vermutung (einer eher unbeteiligten): dein HM-OU-LED16 hoert die ACKs der CUNO
nicht (rechtzeitig?), deswegen sendet er bis zu 3-mal das Kommando aus. Das
ist normal fuer alle HM-Geraete.

[dou...@gmx.de]

Moin Rudolf und danke für die Antwort. 

Ja, das Verhalten passt zu deiner Erklärung. 

Da ich am Display selber nichts ändern kann, blieben nur zwei Möglichkeiten:

In meiner FritzBox steckt ein CUL für die FS20 Kommunikation und der CUNO macht HomeMatic und OneWire.

Ich könnte versuchen den CUL für die HomeMatic Kommunikation zu nehmen. Vielleicht ist er ohne die Netzwerk Latenz schneller?

Oder ich versuche das via Software abzufangen.

Hm... mal sehen...

Ich hatte noch was vergessen:

Ich bin von dem Ding ziemlich begeistert und hab es aktuell tagsüber auf dem Schreibtisch stehen, um nach und nach Dinge zu programmieren. Abends nehm ich es dann mit rauf ins Schlafzimmer. Ich werde (sobald ich es schaffe) einen Kanal um einen kleinen Buzzer erweitern, damit ich eine kleine "Alarmanlage" hab, die mich nachts ggf. weckt.

Frage dazu: wenn ich nur StatusÄNDERUNGEN an das Display sende, bleiben etliche LEDs bis dahin dunkel und ich habe nach der Inbetriebnahme keinen Überblick über die ganzen Stati. Aktuell hab ich ein Heinzungs-Timer-Programm, das alle 10 Minuten aufgerufen wird. An dessen Ende rufe ich ein kleines Programm auf, das alle Stati des Displays sendet. 

Unschön: das erzeugt ne nicht unerhebliche Funklast und müllt das Log voll. 

Ich hab noch nicht ganz verstanden, ob man das Display auch in der Art abfragen kann, das man jederzeit entscheiden kann, ob ein Wert gesetzt werden muss oder nicht?

Also in der 10 Minuten Routine zunächst Status vom Display holen, vergleichen und ggf. nur die nötigen Werte setzen?

VG
Ralf

[dou...@gmx.de]

Nachtrag: ich hab das mit dem Buzzer mal eben nachgeholt. 

Ich hab mir dafür die rote LED oben rechts im Display ausgesucht. Sobald die leuchtet, piepst auch der Buzzer. 

Bezeichnet ist diese mit "D9" im Schaltplan. Die Leuchtdiode liegt einseitig auf Masse und bekommt über einen 270 Ohm Widerstand (R16) +5V von IC4 Pin 15 (74HC595).

Ich habe also Pin 15 von IC4 abgegriffen und mir einen Massepunkt gesucht. Das war's auch schon. Als Funktionskontrolle piepst das Display nach Einstecken des Steckers jetzt zwei mal kurz, wenn die LEDs durchgeschaltet werden (Ein mal für rot und ein mal für orange).

Notiz an mich: nächstes mal Fädeldraht und einen etwas kleineren Buzzer nehmen. 

[Martin]

Hallo Ralf,

1) das ilum auf nur auf das device geht ist klar - es handelt sich ja um die Beleuchtung aller
2) das mit 0 = dauer-AN werde ich in commandref aufnehmen
3) zu den 3-fach messages: kannst du ein Log schicken mit den Messages? Warscheinlich hat Rudi recht - aber ich haette gerne gesehen, ob es ein Fehler ist.
4) Abfrage der LEDs sollte funktionieren mit get <name> param state
  a) wenn es auf einen channel geht kommt die Farbe in klartest
  b) wenn du es auf das Device machst ist es nur ein code
  c) wenn du get nimmst wird der Status aus dem Speicher geholt - also keine messages, keine events, keine Logs

Passt das so? Anregungen?

Gruß
Martin

[dou...@gmx.de]

Moin Martin,

ich versuch's mal :-)

Also: anbei mal ein Auszug aus meinem Log. Der untere Teil ist aus dem "DispUpdate" Programm, das immer nach dem Heizungsprogramm aufgerufen wird. Dort werden aktuell noch "blind" alle derzeit aktiven Kanäle gesetzt. Mehr hab ich noch nicht in Betrieb.

2012-10-01 08:29:39 CUL_HM DLED3 led green

2012-10-01 08:29:39 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 0103020035C00000AA

...

2012-10-01 08:34:28 dummy Casa_Heizung off

2012-10-01 08:34:28 CUL_HM DLED1 led green

2012-10-01 08:34:28 CUL_HM Display_16LED ilum 15 0

2012-10-01 08:34:28 CUL_HM DLED2 led green

2012-10-01 08:34:28 CUL_HM DLED4 led green

2012-10-01 08:34:28 CUL_HM DLED9 led off

2012-10-01 08:34:28 CUL_HM DLED12 led off

2012-10-01 08:34:28 CUL_HM DLED16 led orange

2012-10-01 08:34:29 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 0101020037C00000AA

2012-10-01 08:34:31 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 0102020038C00000AA

2012-10-01 08:34:31 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 0104020036C00000AA

2012-10-01 08:34:32 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 0109000036C00000AA

2012-10-01 08:34:32 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 010C000036C00000AA

Einen raw Mitschnitt sende ich dir im Anhang. Dort hab ich etliche male einen Button am Display gedrückt, um was zu senden. 

Allerdings sehe ich dort die ACKs nicht. (Hab ich mit inform raw aufgenommen)

Kommst du damit zurecht?

Leider bekomme ich sowohl auf ein 

get Display_16LED param state  (Mein Device)

als auch  auf

get DLED1 param state (Channel_01 von meinem Device)

als Antwort "undefined".

Liegt möglicherweise daran, das ich mit deiner Version vom 21.09. arbeite?

VG
Ralf

[Martin]

Hi Ralf,

2012-10-01 08:34:32 CUL_HM Display_16LED noReceiver: src:1AC64D (8002) 010C000036C00000AA

das noReceiver sollte behoben sein - hatte aber wohl keine operationelle Auswirkung.

Leider bekomme ich sowohl auf ein 

get Display_16LED param state  (Mein Device)

als auch  auf

get DLED1 param state (Channel_01 von meinem Device)

als Antwort "undefined".

zu beachten: alle get gehen (bisher jedenfalls) auf die in FHEM vorliegenden Werte. Der Wert 'state' wird nach einem Empfangen gesetzt.War state im web interface zu sehen?

Liegt möglicherweise daran, das ich mit deiner Version vom 21.09. arbeite?

uh - so alt ;-)

Zusammenfassend:
- die no receiver sind in der aktuellen Version (auf SVN) behoben
- das Druecken der Taste sollte verarbeitet worden sein und sollte events generiert haben .
- dein Mitschnitt high level und raws ist nicht vom gleichen Zeitraum

Hast du Probleme mit den Triggern der Tasten?

Gruss
Martin

Gruss
Martin

[dou...@gmx.de]

Hi Martin, 

bitte entschuldige, wenn meine Antworten noch nicht 100% zu deinen Fragen passen. Ich versuche mein Bestes. :-)

Hab heute Morgen ein updatefhem gemacht und seit dem ist etliches anders/besser.

1. Der Event von (z.B.) Button 16 liefert jetzt:

2012-10-01 15:08:31 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-01 15:08:31 CUL_HM Display_16LED Btn16: on (to CUNO_2)

In diesem Fall war die Rückmeldung vom Display übrigens "rot" - also nicht erfolgreich. Kommt von 10 Versuchen vielleicht 2 mal vor. Da hier aber inzwischen 10 HM-CC-TCs und 11 VDs im Einsatz sind, könnte es theoretisch manchmal eng im Luftraum werden.

Warum wird das eigentlich ein mal mit und ein mal ohne ":" gelisted?

Ich hab mir mein notify umgeschrieben, das es die Nummer des gedrückten Buttons abfängt, aber ich muss noch mal bei den regexp nachlesen, wie ich die mit dem ":" unterdrücke. 

2. Mein DispUpdate Programm sieht jetzt so aus. Ich hoffe ich hab das richtig verstanden, weil ich (versuche) mit "get param state" ein Update des Device zu machen, damit die anschliessenden ReadingsVal die aktuellen Werte beinhalten.

Oder mach ich da einen Gedankenfehler?

sub

prg_DispUpdate()

 {

   fhem ("get Display_16LED param state"); # Get current status

   if (isday() && !$data{Hallentor_auf_notify}) {

   fhem ("set Display_16LED ilum 15 0")

   } else {

   fhem ("set Display_16LED ilum 1 15")

   };

# Channel 1 

# Casa_Heating

#

   if (Value("Casa_Heizung") eq "off") {

     if (ReadingsVal("DLED1", "state", "") ne "green") {fhem ("set DLED1 led green")}

   } else {

    if (Value("Casa_Heizung") eq "on") {

     if (ReadingsVal("DLED1", "state", "") ne "orange") {fhem ("set DLED1 led orange")}

    }

   };

# Channel 2

# MansCave Hallentor

#

   my $tor=ReadingsVal("Halle_1W", "Tor", "");

   if (substr($tor, 0, 2) eq "Zu") {

     if (ReadingsVal("DLED2", "state", "") ne "green") {fhem ("set DLED2 led green")}

   } else {

   if (substr($tor, 0, 3) eq "Auf"){

     if (ReadingsVal("DLED2", "state", "") ne "orange") {fhem ("set DLED2 led orange")}

    }

   };

#

# Channel 3 

# MansCave Hallenfenster

#

   my $fen=ReadingsVal("Halle_1W", "Fenster", "");

   if (substr($fen, 0, 2) eq "Zu") {

     if (ReadingsVal("DLED3", "state", "") ne "green") {fhem ("set DLED3 led green")}

   } else {

   if (substr($fen, 0, 3) eq "Auf"){

     if (ReadingsVal("DLED3", "state", "") ne "orange") {fhem ("set DLED3 led orange")}

    }

   };

#

[Martin]

Hallo Ralf,

1)freut mich, wenn etwas funktioniert.
1a) der ":" - ja, da stimmt etwas nicht
 der erste event ist der Status - werde ich aendern auf

2012-10-01 15:08:31 CUL_HM Display_16LED Btn16 on

1b)
der 2. ist eigentlich doppelt... aber manche brauchenes, da werden ich das target drin lassen

2012-10-01 15:08:31 CUL_HM Display_16LED Btn16: on (to CUNO_2)

den : lasse ich besser mal drin... fuer andere user

2) muss ich mir noch einmal ansehen.
Hintergrund
Das get habe ich eingebaut damit man nicht die Variablen direkt lesen muss. Beispielsweise hatte einer der Tester Probleme das "model" eines Kanals zu lesen - model steht nicht mehr in der Definition des Kanals. Aber die Methode sucht den korrekten Wert.
Alle get gehen nicht an die HW sondern lesen nur die Werte aus dem fhem-speicher.
Einen bug habe ich noch - wenn du reading-werte liest kommt ein fuehrendes "4:" - werde ich entfernen, hat keine Bedeutung

Wenn ich deinen Code verstanden habe, melde ich mich ;-)
Gruss
Martin

[dou...@gmx.de]

Vergiss meinen Code! Das ist alles noch mit der Axt zusammen gehauen! (Und tut auch nur das war du gesagt hast) :-)

Was ich eigentlich vor hatte war, die Werte aus der Hardware zu lesen, oder ersatzweise, alle Werte in fhem updaten zu lassen (indem das Display mal alles sendet). Dann käme ich anschliessend wieder mit ReadingsVal oder get weiter.

Aktuell kann ich aber nicht erkennen, ob eine LED auf dem Display an oder aus ist. 

Sorry, wenn die Frage ev. blöd ist. 

VG
Ralf

[Martin]

Aktuell kann ich aber nicht erkennen, ob eine LED auf dem Display an oder aus ist. 

Sorry, wenn die Frage ev. blöd ist. 

 warum nicht?
1) FHEM ist auf dem Aktuellen Stand alles "Aenderungen".wenn man die startphase ausser acht laesst wird jede aenderung in den parametern sichtbar
a) auf Kanal ebene in READINGS state kannst du die Farbe lesen (natuerlich die des Kanals, also der LED)
b) auf device ebene sind noch einmal alle zusammengefasst. - ok, der Wert ist in hex, je 2 bit pro LED...
=> ein Probleme kannst du nur haben wenn FHEM gestartet ist oder sonstwie messages verloren gegangen sind
=> ein Problem habe ich, da 'state' mit dem allgemeinen device 'state' kollidiert und es Probleme bei der Abfrage mit get param gibt.
=> ich benenne es um in READINGS "color"

2) kannst du den Zustand nicht mit statusRequest lesen? Die Antwort wird in state (Ende der Woche "color") abgelegt

Gruss
Martin

[dou...@gmx.de]

Am Dienstag, 2. Oktober 2012 08:38:13 UTC+2 schrieb Martin:

1) FHEM ist auf dem Aktuellen Stand alles "Aenderungen".wenn man die startphase ausser acht laesst wird jede aenderung in den parametern sichtbar

Du hat völlig recht Martin, nur mein "Problem" ist, das mein Display eben manchmal nicht auf dem aktuellen Stand ist. :-)

Hab oben geschrieben, das das Ding tagsüber auf dem Schreibtisch steht, und ich das dann Abends mit nach oben nehme. In dem Moment verliert es seinen "Status" und zeigt lediglich was an, wenn sich Werte ändern, weil ich nur Änderungen sende.

Aber mein Anwendungsfall ist so ungewöhnlich, das ich nicht erwarte, das die Software so was vorhersieht. 

Ich werde das anders lösen, in dem ich mir auf einen Button eine "Update-Funktion" programmiere, die dann alle Kanäle setzt, und dann nur noch Änderungen übertragen werden. Das erspart 16 Telegramme pro Zyklus. 

Aber ich bin nach wie vor begeistert von deiner/eurer Arbeit und fhem an sich. Tolle Sache, und ich lerne jeden Tag dazu.

VG
Ralf

[Martin]

Ralf,

danke
aber ich bin neugierig.
Warum verliert es die Daten?
Macht es einen power-cycle? kommt da eine message? und wens klappt auch ein power-on event?
Martin

[dou...@gmx.de]

Power-Cycle.

Es handelt sich um ein Gerät mit kleinem Steckernetzteil :-)

[Martin]

Am Dienstag, 2. Oktober 2012 10:49:38 UTC+2 schrieb dou...@m1n1.de:

Power-Cycle.

Es handelt sich um ein Gerät mit kleinem Steckernetzteil :-)

cool - kommt auch der event powerOn? da kannst du deine LED neu setzen und abgragen und und.
Man kann natuerlich einbauen, dass nach powerOn die LEDs auf den Zustand des speicher gesetzt werden - wuerde Sinn machen. Das betrifft nicht nur dich sondern jeden, der mal kurz den Stecker zieht

[fhem-hm-knecht]

Nach dem einstecken kommt das


2012-10-02 12:03:31 CUL CUL2 RCV L:0D N:00 F:A4 CMD:10 SRC:LED
DST:F12222 06000000 (INFO_ACTUATOR_STATUS) (,BCAST,BIDI,RPTEN)
2012-10-02 12:03:31 CUL CUL2 SND L:0A N:00 F:80 CMD:02 SRC:F12222
DST:LED 00 (ACK) (,RPTEN)
2012-10-02 12:03:31 CUL_HM LED powerOn:

hary

[dou...@gmx.de]

YES!!!

2012-10-02 12:02:32 CUL_HM Display_16LED powerOn: 

Martin, you made my day! :-)

Das hab ich noch nie gesehen!!! Und das löst mein Problem! :-)

DANKE! 

[dou...@gmx.de]

Das Leben kann sooo einfach sein! :-)

define DispLed16_powerOn_notify notify Display_16LED.powerOn:.* {prg_DispForceUpdate}

[Martin]

in der aktuellen Version sollte es automatisch gehen. Kann es leider nicht testen - kannst du einmal versuchen?
Danke

[dou...@gmx.de]

Danke Martin, aber so weit komme ich noch nicht.

Ich hab immer noch das Problem, das wenn ich einen Button am Display drücke, die Meldung mehrfach kommt. Dabei ist es offenbar egal, ob vom Display ein ACK oder nicht empfangen wird.

Hier mal ein Auszug aus dem Event-Log

Ich hab den Befehl drei mal versucht abzusetzen. Da ich in meinem notify nach "Display_16LED:Btn.*" parse, gibt es immer zwei Befehle, die sich beim togglen aufheben.

Da ich aber diese Display Geschichte für deutlich weniger wichtig als die HM-CC-TC Sache halte, wollte ich mich mal mit Kommentaren zurück halten, bis das andere erst mal läuft. :-)

2012-10-05 15:08:29 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-05 15:08:30 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-05 15:08:35 CUL_HM Display_16LED resend nr 2

2012-10-05 15:08:35 CUL_HM Display_16LED resend nr 3

2012-10-05 15:08:37 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-05 15:08:38 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-05 15:08:58 CUL_HM Display_16LED Btn16 on (to CUNO_2)

2012-10-05 15:08:59 CUL_HM Display_16LED Btn16 on (to CUNO_2)