Hallo,
nun habe ich mir auch eine HM-RC-19 zugelegt. Mit fehm gepaired, ebenso eine HM-LC-Sw1-PI-2 Funkschaltsteckdose. Die Steckdose mit Btn01 der Fernbedienung gepeered. Klappt wunderbar.
Allerdings zeigt das Display der Fernbedienung beim Schalten 100 (für An) bzw 0 (für Aus) an. Das Handheftchen sagt die Fernbedienung kann an hand der angelernten Aktoren unterschiedliche Schaltzustände darstellen. Meine Interpretation ist, dass für Schaltaktoren An bzw Aus angezeigt werden.
Ist mit fhem möglich der Fernbedienung mitzuteilen, dass auf Btn01 ein Schaltaktor ist?
Und dann habe ich noch eine weiter Frage - auf dem Display kann man ja Text ausgeben. Ist es auf einfachen Weise möglich beim Betätigen von Btn01 eine textliche Rückmeldung zu geben?
Danke schon mal und ciao
walter
Kleine Spielerei meinerseits.
################################################
#####
################################################
define FunkFernbedienung19T_Display notify SchaltSteckdose_01:.*(on|off) { \
# Log 1, ">>> Value is $EVENT";; \
fhem("set FunkFernbedienung19T_Disp display Deko no off 1 on bulb");; \
fhem("set FunkFernbedienung19T_Disp display Esszi no off off on bulb");; \
if ($EVENT eq "on") { \
fhem("set FunkFernbedienung19T_Disp display An no off off on bulb");; \
} \
if ($EVENT eq "off") { \
fhem("set FunkFernbedienung19T_Disp display Aus no off off on bulb");; \
} \
}
Leider nicht allzu performant.
ciao walter
Folgendes Setting zeigt keine Wirkung:
set FunkFernbedienung19T_Disp regSet msgShowTime 5
Auf dem FB Display wird CONFIG angezeigt, aber nach einem getConfig stehen weiterhin 30s in den Readings.
ciao walter
Hallo Walter,
zum einen kann man bei der RC19 das Display setzen, was du ja schon machst.
neu fuer mich ist, dass die RC19 selbstaendig die 0 oder 100 anzeigt. Ich gehe davon aus, dass sie dies aus dem ACK deiner Steckdose entnimmt - hier werden schaltzustaende immer in % angegeben. Steckdosen und dimmer,... unterschieden sich hier nicht, ausser dass bei einer Steckdose keine zwischenwerte kommen, klar.
Dass die RC19 noch mehr inteligenz hat und anhand des Type die "100" in "on" unsetzt kenne ich nicht. Aber man kenn eine "language" setzen. Evtl hat dass einen Einfluss?
ZitatFolgendes Setting zeigt keine Wirkung:
set FunkFernbedienung19T_Disp regSet msgShowTime 5
Die 30sec, die im Config stehen stimmen auch? Es ist also 30sec an?
kannst du einmal logs davon ziehen?
attr verbose 1
attr mseclog 1
attr <hmlan> loglevel 1
set FunkFernbedienung19T_Disp regSet msgShowTime 5
set FunkFernbedienung19T_Disp getConfig
Gruss Martin
p.s. hast du die anderen Funktionen und Register schon getestet? Was ist noch offen, was geklaert?
Hallo Martin,
Die die Anzeigezeit entspricht den 30s von getConfig.
Wrede die Daten am Wochenende liefern, Dich aktuell beruflich unterwegs bin. Check auch dann die anderen register durch.
Ciao Walter
Hallo Martin,
die Situation mit der Fernbedienung ist mittlerweilen in einem schlechten Zustand :-(
Am Samstag habe zu viele Änderungen durchgeführt - 2ten repeater, update - nicht nachvollziehbar war über dem HMLAN keine vernünftige Kommunikation mehr möglich. Also alles zurück, fhem auf den Stand vor dem update und den repeater wieder raus.
Tests mit der Fernbedienung > generelle Probleme mit der HMLAN Kommunikation nach ein paar Tests. Auch nach einem erneuten fehm update. Scheint nicht an den Versionen zu liegen.
Beim mit-tracen der log Datei ergibt sich nach einem Neustart von HMLAN folgendes:
set Funk_FB19T regSet backAtMotion off > zuerst getConfig Fehlermeldung von fhem
getConfig durchgeführt > ok
erneut set Funk_FB19T regSet backAtMotion off > Licht an bei Erschütterung abgeschalten
erneut getConfig > nach kurzer Zeit tauchen NACKs im log auf. Etwas danach der Hinweis es ist ein Problem aufgetreten und es ist ein Neustart nötig
ab jetzt ist die Kommunikation auch mit anderen HM-Geräten gestört
also Neustart HMLAN
die angehängte log-Datei enthält zwei getConfigs. Das erste scheint nicht erfolgreich zu sein, das zweite erzeugt das Neustart-Problem.
Ich versuche noch eine log-Datei nach der obiegen Beschreibung hinzubekommen.
ciao
walter
noch etwas was ich beobachten konnte:
nachdem ich die FB und die Schaltsteckdose zurückgesetzt hatte, habe ich sie direkt (ohne) fhem angelernt. Beim Schalten bekomme ich ein grünes Licht und den Status An/Aus im Display (und icon Schalter). Dabei ist der Schaltzustand An auf der linken Taste und Aus auf der rechten Taste.
beide wieder zurückgesetzt mit fhem gepaired und untereinander gepeered. Nun bekomme ich ein gelbes Licht und keinen Status im Display. Das Schalten der Zustände geschieht über eine Taste. Einmal Drücken > An, nochmal > Aus
Nachtrag: im _Btn1 wurde die peer Information nicht eingetragen. Mit ... remote nachgetragen > beim Betätigen der Taste gibt es nun ein grünes Licht und im Display werden 0 und 100 angezeigt. Kein icon :-(
ciao walter
Hallo Walter,
habe gerade in deine Logs hineingesehen.
So nebenbei
- mseclog war nicht an, waere besser mit
- HMID 1888B0 1B7B09 1B7C04, sind das Ventile? Da funktioniert die Kommunikation nicht korrekt
- ab 09:41:34 hat sich ein Problem mit hmlan aufgeschaukelt. Kommunikation war nicht mehr moeglich, nur nich mitmessen
Es gibt einen overlap der Verarbeitung, massages werden einen tick zu frueh gesendet. Dazu brauche ich die millisekunden aufloesung.
Was ich nicht gesehen habe ist, wie/wo du die showtiem aendern wolltest. Ist das drin?
Das erste getConfig ist sauber zu sehen.
Gruss
Martin
Hallo Martin,
diesmal mit mseclog.
Leider bekomme ich ein erfolgreiches getConfig nicht mehr hin. Es läuft zwar beim ersten Mal 'sauber' durch, aber das folgende setReg behauptet es muss zuerst ein getConfig durchlaufen. Ein weiteres getConfig endet dann mit der log-Aussage 'problems detected - please restart'.
ciao walter
Hallo,
kann es evtl. sein, dass dieser Status (0408) des HMLAN die Überschreitung der Sendezeit (1%-Regel) anzeigt?
Zumindest hab ich mir das so erklärt, da die RC-19 ja ein Burst-Device ist und vor jedem Paket ein 360ms Burst erzeugt wird und man nur 36s/h senden darf (ich hatte genau die gleichen Probleme mit meiner RC19 und habe dann nach jedem getConfig den HMLAN rebootet)...
Es sind bei einer RC19 ja nicht gerade wenig getConfig-Pakete.
Vielleicht liege ich hier aber auch komplett daneben.
Gruß
Michael
Hallo Michael,
nein, daneben liegst du nicht.
Dein HMLAN hat sich 'erhängt' - mindestens auf einem Port zum RC19.
Leider weiss ich nicht, wie man den HMLAN rücksetzt oder wie man dieses Port bereinigtt, ausser power-down.
Die Ursache scheint zu sein, dass ich etwas zu schnell sende - eine verzögerte Message des RC19 hat mich Überrascht.
Neue SW kommt gleich - dann bitte noch einmal probieren und ggf noch einmal die gleichen Traces (oder besser traces in jeden Fall)
Gruss Martin
Hallo Martin,
eben das update installiert.
Erstes getConfig läuft super. Das Kommando set ... setReg backAtMotion off abgesetzt. Erneutes getConfig, erneut kein Problem. Das Setting von backAtMotion wird richtig angezeigt.
Noch ein getConfig - nun taucht das alte Problem auf. Zuerst das NACK Problem, dann die Aufforderung zum restart.
Da ich aktuell in Hannover an der Hotelbar sitze, kann ich Dir die logs erst Ender der Woche emailen.
ciao walter
Hallo,
ich habe das gestern Abend nochmal nachgestellt:
1. getConfig: keine Probleme
2. getConfig: mittendrin dann 0804-Fehler vom HM-CFG-USB
Danach hab ich noch ein paar Lampen geschaltet, bis auch hier nur noch 0804-Fehler kamen.
Nach einer Stunde konnte ich dann ein 3. getConfig ohne Fehler auf die Fernbedienung machen, ohne irgendetwas anzufassen oder neuzustarten.
Daraus schliesse ich, dass der HM-CFG-XXX den Status 0804 ausgibt, wenn das zu sendende Paket die 1%-Regel überschreiten würde. Deswegen konnte ich auch noch ein paar Lampen schalten, da diese Pakete keine 360ms Preamble vor den eigentlichen Daten haben.
Ich bin mir allerdings nicht sicher, was der beste Weg ist mit 0804 umzugehen:
1. Alle anstehenden Pakete in eine Warteschlange und es so oft probieren bis der Status nicht mehr 0804 ist
2. Verhalten wie bisher, also Pakete nach ein paar fehlgeschlagenen Sendeversuchen verwerfen, dafür aber die Log-Meldung anpassen (LOVF oder so, Hinweis auf Restart raus)
Gruß
Michael
Hallo Michael,
der Status kann nach meinen Beobachtungen folgenden Werte haben - wichtig ist hier wohl nur das high-byte
01xx => alles ok
02xx => Probleme, arbeitet nicht mehr
04xx => weitere Eskalation, next level zu 02xx
08xx => deine interpretation 1% regel?
Ich denke auch, dass es etwas mit ueberlast, queue overflow oder sonstigen zu tun hat. Das mit der 1% regel werde ich einmal testen.
Mein kuerzlich gefaster Plan ist, den Zustand zu provorieren, dann die HM config SW am PC starten und mit wireshark beobachten, ob HM den Zustand 'reparieren' kann.
Hast du die Stati 02xx und 04xx auch schon gesehen? Bei beiden kann ich noch Infos empfangen, aber nichts senden. Wie ist dies bei 08xx?
Gruss Martin
Hallo Martin,
Zitat von: martinp876 schrieb am Mi, 19 Juni 2013 10:0808xx => deine interpretation 1% regel?
Äh, mach bitte ein s/0804/0408/g über meinen Post. 08xx hab ich bisher nicht gesehen, das war ein Typo heute morgen, Sorry.
Bei 0408 kann man weiterhin empfangen und der Status verschwindet dann nach einiger Zeit (sah sehr nach 1h aus).
Gruß
Michael
Hallo Michael,
nun, das habe ich dann schon alles gesehen. Gut erst einmal.
Dass es etwas mit einer ueberlast zu tun hat war klar, der Hinweis mit msgs/h hatte ich nicht im Blick
xx08 bedeuted normal: message mit ack request gesendet aber kein ACK erhalten
somit ist
0008 : 3 mal gesendet, kein ACK
0408 : nicht gesendet, kein ACK (klar)
Mit dem erweiterten Hintergrung werde ich Versuche anstellen...
Auf jeden Fall werde ich einen entsprechendes Status-reading einbauen.
Kommandos 1h queuen halte ich fuer nicht sinnvoll, ggf sogar gefaehrlich. Da koennten ploetzlich Lichter ein/ausgeschaltet werden, Steckdosen unter spannung kommen, 1h nach der Aktion... Rollos fahren in ungewuenschte Positionen, Tueren werden verschlossen... Das kann man nicht machen.
Generell sind die 'proto...' parameter geeignet, es abzubilden. Ausserdem braucht man noch ein Reading, um notifies anbinden zu koennen.
Jetzt aber erst einmal den Mechanismus verstehen und ausmessen
Gruss Martin
Hallo Martin,
hast Du damit alles was Du brauchst oder soll ich Dir noch die Log-Informationen zusammenstellen?
ciao walter
soweit habe ich alles, danke.
Die Messungen werden etwas dauern...
so, hier mal ein Zwischenstatus - fuer den Fall dass jemand noch Erkentnisse oder Ideen hat
- es gibt 2 'status' 02 und 04, welche beiden einen Overload-level anzeigen
- ich kann beiden reproduzieren, aber nicht sehr gezielt. Eine klare Formel konnte ich nicht identifizieren.
- 02 koennte ein warning-level sein. Im Prinzip funktioniert noch alles
- 04 ist ein error-level. Der Transmitter sendet nicht mehr (main process und LAN interface scheinen immer noch 'normal' zu arbeiten)
- HMLAN ist in beiden Faellen immer noch in der Lage, alles zu monitoren. Empfangen ist also kein Problem, nur der Transmitter ist betroffen.
Recovery
- power-down funktioniert
- ein reset kommando gibt es sicher... leider kenne ich es nicht
- HMLAN erholt sich selbstaendig, je nach Level so nach 5-10 min. In dieser Zeit duerfen keine Sendeauftraege stattfinden.
Geplante Implementierung
+ unstrittig
- HMLAN wird ein Reading erhalten, dass den Transmitter-Zustand darstellt. Somit kann man mit notifies arbeiten
- FHEM wird bei erreichen des error-level fuer eine gegebene Zeit das Senden blockieren. Das wird nach bisherigen Messungen so bei 3-5min liegen.
- ein power-down des HLMAN wird auch den timer loeschen
- Es wird Zaehler in HMLAN geben, die Auskunft ueber die Haefigkeit der Problem gibt
+ (etwas) fraglich
- da eine Wartezeit von 5 min erheblich ist stellt sich die Frage, was man mit wartenden oder eingehenden Kommandos zu machen ist. Aktuell plane ich, alle Kommandos, die in der fraglichen Zeit kommen zu loeschen.
- Im CUL_HM Device wird es einen Zaehler "protoIOerr" geben, der dies erfasst.
Das Senden zu verzoegern halte ich fuer unklug/gefaehrlich. Es sind nicht nur getConfig oder peering kommandos sondern auch schalt-kommandos , incl tuerverriegelungen. Auch wenn jemand etwas an der Steckdose macht und diese ploetzlich einschaltet...
Das ganze wird freundlicher, falls wir entsprechende rueckstell kommandos des HMLAN finden
Gruss
Martin