Originally posted by: <email address deleted>
...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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
On Thursday, September 27, 2012 3:37:45 PM UTC+2, dou...@m1n1.de wrote:
>
> ...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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
On Thursday, September 27, 2012 3:48:44 PM UTC+2, dou...@m1n1.de wrote:
>
> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
On 27 Sep., 15:48, "dou...@m1n1.de" wrote:
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
..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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 _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 ++A011820001 # sleep mode on
raw ++A011820000 # sleep mode off
oder falls es mit Kanal geht:
raw ++A011820101 # sleep mode on
raw ++A011820100 # sleep mode off
Dann waere noch ein Kommando erforderlich
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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?
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
>
>>
>> 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?
>
>>
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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?
VG
Ralf
>>>
>>> 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?
>>
>>>
>>>
>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
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
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
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
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
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
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
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
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
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
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
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
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
Originally posted by: <email address deleted>
in der aktuellen Version sollte es automatisch gehen. Kann es leider nicht
testen - kannst du einmal versuchen?
Danke
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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)
Am Freitag, 5. Oktober 2012 13:39:41 UTC+2 schrieb Martin:
>
> in der aktuellen Version sollte es automatisch gehen. Kann es leider nicht
> testen - kannst du einmal versuchen?
> Danke
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com