HomeMatic 16 LED Display HM-OU-LED16

1921 views
Skip to first unread message

dou...@gmx.de

unread,
Sep 27, 2012, 9:37:45 AM9/27/12
to fhem-...@googlegroups.com

...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

unread,
Sep 27, 2012, 9:46:01 AM9/27/12
to fhem-...@googlegroups.com
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

unread,
Sep 27, 2012, 9:48:44 AM9/27/12
to fhem-...@googlegroups.com

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

unread,
Sep 27, 2012, 9:54:43 AM9/27/12
to fhem-...@googlegroups.com
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

unread,
Sep 27, 2012, 9:55:42 AM9/27/12
to FHEM users
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

unread,
Sep 27, 2012, 11:41:37 AM9/27/12
to fhem-...@googlegroups.com

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

unread,
Sep 27, 2012, 12:16:51 PM9/27/12
to fhem-...@googlegroups.com
> 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

unread,
Sep 27, 2012, 2:39:46 PM9/27/12
to fhem-...@googlegroups.com

..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

unread,
Sep 28, 2012, 2:43:19 AM9/28/12
to fhem-...@googlegroups.com
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

unread,
Sep 28, 2012, 4:29:52 AM9/28/12
to fhem-...@googlegroups.com

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

unread,
Sep 28, 2012, 5:33:48 AM9/28/12
to fhem-...@googlegroups.com


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

unread,
Sep 28, 2012, 9:09:28 AM9/28/12
to fhem-...@googlegroups.com

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

unread,
Sep 29, 2012, 2:04:29 AM9/29/12
to fhem-...@googlegroups.com

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

unread,
Sep 30, 2012, 3:30:07 AM9/30/12
to fhem-...@googlegroups.com
 
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

unread,
Sep 30, 2012, 3:39:15 AM9/30/12
to fhem-...@googlegroups.com
> 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

unread,
Sep 30, 2012, 4:10:14 AM9/30/12
to fhem-...@googlegroups.com


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

unread,
Sep 30, 2012, 9:21:56 AM9/30/12
to fhem-...@googlegroups.com


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

unread,
Sep 30, 2012, 1:36:17 PM9/30/12
to fhem-...@googlegroups.com
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

unread,
Oct 1, 2012, 3:01:30 AM10/1/12
to fhem-...@googlegroups.com


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
HM_OU_16LED_Test.zip

Martin

unread,
Oct 1, 2012, 4:05:37 AM10/1/12
to fhem-...@googlegroups.com

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

unread,
Oct 1, 2012, 9:24:57 AM10/1/12
to fhem-...@googlegroups.com

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

unread,
Oct 1, 2012, 2:44:22 PM10/1/12
to fhem-...@googlegroups.com
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

unread,
Oct 2, 2012, 2:16:10 AM10/2/12
to fhem-...@googlegroups.com

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

unread,
Oct 2, 2012, 2:38:13 AM10/2/12
to fhem-...@googlegroups.com


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

unread,
Oct 2, 2012, 3:40:54 AM10/2/12
to fhem-...@googlegroups.com



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

unread,
Oct 2, 2012, 3:57:12 AM10/2/12
to fhem-...@googlegroups.com
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

unread,
Oct 2, 2012, 4:49:38 AM10/2/12
to fhem-...@googlegroups.com

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

Martin

unread,
Oct 2, 2012, 5:54:16 AM10/2/12
to fhem-...@googlegroups.com


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

unread,
Oct 2, 2012, 6:05:41 AM10/2/12
to FHEM users
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

unread,
Oct 2, 2012, 6:07:19 AM10/2/12
to fhem-...@googlegroups.com

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

unread,
Oct 2, 2012, 6:23:57 AM10/2/12
to fhem-...@googlegroups.com


Das Leben kann sooo einfach sein! :-)

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

Martin

unread,
Oct 5, 2012, 7:39:41 AM10/5/12
to fhem-...@googlegroups.com
in der aktuellen Version sollte es automatisch gehen. Kann es leider nicht testen - kannst du einmal versuchen?
Danke

dou...@gmx.de

unread,
Oct 5, 2012, 9:15:45 AM10/5/12
to fhem-...@googlegroups.com


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)
Reply all
Reply to author
Forward
0 new messages