HomeMatic 16 LED Display HM-OU-LED16

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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.

<https://lh5.googleusercontent.com/-Fi2YxlilC7Q/UGhHAd2b9qI/AAAAAAAAWeI/I7b3Smxy3YM/s1600/DSC_6116small.jpg>


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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")}
    }
   };
#




--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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




--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[LuckyDay]

                                         

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
On 2 Okt., 11:54, Martin wrote:
> 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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!

Am Dienstag, 2. Oktober 2012 11:54:16 UTC+2 schrieb 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
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das Leben kann sooo einfach sein!

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com