Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[b4rRa]

So ich melde mich noch mal zu Wort.. Habe jetzt einige HM-LC-Sw1PBU-FM mit alternativer Firmware im Betrieb. Die Schalter funktionieren soweit.. Leider habe ich auch das Problem, dass sich die Schalter offenbar nach einer gewissen Zeit "aufhängen" und sich dann am Taster nicht mehr schalten lassen - aber auch nur dort. Wird dann irgendeine Aktion über FHEM an den Schalter gesendet, funktioniert es auch wieder direkt am Taster.

Ich konnte hier nicht wirklich irgendeine Regelmäßigkeit feststellen. Mal tritt es nach nem halben Tag auf, mal läuft es 3 Tage ohne Probleme... Dennoch trägt dies natürlich nicht zum WAF bei.

Beim stöbern des Threads habe ich einige Leute gefunden, die das gleiche Phänomen haben. Aber irgendwie keine wirkliche Lösung? Liest hier noch jemand von den Betroffenen mit und hat vlt. mittlerweile einen Lösungsansatz dafür?

Wenn sich der Schalter aufhängt, kommen keinerlei Eingaben mehr in FHEM an. Der Eventmonitor bleibt komplett leer. Sobald ich über FHEM das Relais einmal schalte, funktioniert auch am Taster direkt wieder alles wunderbar. Es reicht sogar ein einfaches getConfig auf den Schalter und er lässt sich danach wieder einwandfrei bedienen.

Mir ist aufgefallen, dass der Schalter - sobald er sich aufhängt - auch nicht mehr die Current Status Updates sendet, die normalerweise im 20 Sekunden Takt kommen. Ist es nicht möglich mit irgendeiner Routine die Current Nachrichten auf den Aktor zu loggen und sobald z.B. 3 Minuten keine Current Status Updates mehr kommen, er automatisch ein getConfig ausführt? Der Current Parameter selbst ändert sich ja nicht, also müsste die Abfrage irgendwie auf den Timestamp oder Logeintrag erfolgen. Aber ich hab keine Ahnung wie ich das umsetzen muss, falls das überhaupt geht

Code Auswählen Erweitern

2017-03-29_14:04:12 Elektronikecke current: 0
2017-03-29_14:04:31 Elektronikecke current: 0
2017-03-29_14:04:50 Elektronikecke current: 0
2017-03-29_14:05:08 Elektronikecke current: 0
2017-03-29_14:05:27 Elektronikecke current: 0
2017-03-29_14:05:46 Elektronikecke current: 0
2017-03-29_14:06:05 Elektronikecke current: 0 ------> Taster hängt sich auf - Keine Statusupdates mehr, Kein Schalten am Taster mehr möglich
2017-03-29_16:23:38 sw_Elektronikecke CMDs_pending ------> getConfig über FHEM ausgeführt
2017-03-29_16:23:38 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:38 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 sw_Elektronikecke CMDs_pending
2017-03-29_16:23:39 Elektronikecke current: 0                 ------> Wieder "da", sendet wieder Status Updates und lässt sich auch am Taster wieder bedienen
2017-03-29_16:23:58 sw_Elektronikecke CMDs_done

[hexenmeister]

Man könnte das folgendermaßen realisieren: mit einem "at" alle 2-3 Minuten eine perlfunktion aufrufen (diese legt man in einem 99_myUtils oder so ab). Diese liest den timestamp des attributes und prüft einfach, ob dieser länger als X in der Vergangenheit liegt. Dann ggf. fhem("set <name> getConfig") aufrufen.

[frank]

oder einen watchdog auf das currentreading, so dass jedes current event den watchdog zurücksetzt. wenn die events ausfallen wird der watchdog getriggert und führt das getconfig aus. geht natürlich auch mit doif.

[b4rRa]

Danke für die beiden Rückmeldungen.. Als Vollpfosten des Scriptings habe ich etwas herumgesucht und bin in der Wiki bei der manuellen Batteriestatusprüfung auf das perfekte Beispiel gestoßen. Ich habe deshalb die Variante von hexenmeister mit myUtils "umgesetzt" und minimal angepasst.

99_myUtils.pm

Code Auswählen Erweitern


sub check_if_alive($$) {
  my ($Device,$minutes_threshold) = @_;
  my ($Device) = @_;
  my $now = time;
  my $Timestamp = ReadingsTimestamp($Device,"current","0");
  if ($Timestamp eq "0") {
    return 2;
  }

  my @splitdatetime = split(/ /,$Timestamp);
  my @splitdate = split(/-/, $splitdatetime[0]);
  my @splittime = split(/:/, $splitdatetime[1]);
  my $last_state_time =  timelocal($splittime[2], $splittime[1], $splittime[0], $splitdate[2], $splitdate[1]-1, $splitdate[0]);
  my $age_in_minutes = ($now - $last_state_time) / 60;
  my $age_in_seconds = ($now - $last_state_time);

  if ($age_in_minutes > $minutes_threshold) {
    Log 1, ("check_if_alive: $Device DEAD - getConfig eingeleitet - Letzter Empfang war vor $age_in_seconds Sekunden");
    fhem ("set $Device getConfig");
  } else {
    Log 1, ("check_if_alive: $Device AKTIV, letzter Empfang war vor $age_in_seconds Sekunden");
  }
   
}


und mit

Code Auswählen Erweitern

define Switch_Check at +*0:03:00 {check_if_alive("Elektronikecke", 3)}

alle 3 Minuten auf aktuelle Currentmeldungen überprüfen. Erster Test sieht sehr gut aus Jetzt muss ich mir nur noch ein notify frickeln, falls der Switch ein set on/off verbummelt. Kommt leider auch ab und an vor.

[Nighthawk]

Hallo Zusammen,

bei mir sind seit einiger Zeit 2 modifizierte Schalter im Einsatz, diese verrichten ihren Dienst meistens gut.
Was mich noch stört ist, dass nach einem Stromausfall 1. meisst das Licht angeht und 2. die internen Peerings gelöscht sind (das mit dem peeren in der Firmware hat bei mir immer nur Probleme verursacht).
Des Weiteren ist mir oft genug aufgefallen dass der Zustand der Lampe nicht korrekt dargestellt wird (meisstens Morgens, wenn das Licht über den Schalter eingeschaltet wird), wobei der Current Wert aber korrekt ist.
Zumindest für den fehlerhaften Zustand haben hier einige geschrieben dass es über ein Notify abgefangen werden kann. Da wäre ein Beispiel für Anfänger sicherlich hilfreich.

[Tobias]

Des Weiteren ist mir oft genug aufgefallen dass der Zustand der Lampe nicht korrekt dargestellt wird (meisstens Morgens, wenn das Licht über den Schalter eingeschaltet wird), wobei der Current Wert aber korrekt ist.

Ich habe 6 modifizierte Schalter im Einsatz und dieses Phänomen habe ich leider auch öfters
Der Zustand der unmodifizierten Schalter ist in FHEM praktisch immer korrekt.

Gesendet von meinem Leap mit Tapatalk

[Nighthawk]

Ich habe das jetzt erstmal folgendermaßen gelöst:

Code Auswählen Erweitern

define Lichtschalter_Zustandskorrektur_ON notify if (Lichtschalter eq "on" and Lichtschalter:current<100)
(set Lichtschalter off)
ELSE (
if (Lichtschalter eq "off" and Lichtschalter:current>200)
(set Lichtschalter on)
)

Scheint so zu funktionieren, falls jemand Verbesserungen, bzw. Optimierungen hat, immer her damit.

[tante ju]

Hat schonmal jemand geschafft, die Firmware mit einem Arduino 1.6 zu bauen?

Sonst muß ich mich selber dransetzen, das jabduino mal auf eine Arduino IDE der letzten Jahre anzupassen.

[Fritz!Maxi]

Hat schonmal jemand geschafft, die Firmware mit einem Arduino 1.6 zu bauen?
...

Ist bei mir nie geglückt. Ich nutzte unter Windows immer noch die 1.0.5-r2 dafür.

[Habbi]

Ist bei mir auch  nie geglückt   Unter Windows  benutzr ich die 1.0.5-r2 dafür.

[tante ju]

Ist bei mir nie geglückt. Ich nutzte unter Windows immer noch die 1.0.5-r2 dafür.

Ist bei mir auch  nie geglückt   Unter Windows  benutzr ich die 1.0.5-r2 dafür.

Hab kein Windows. Habe auf dem Mac mit Arduino IDE 1.0.6 hinbekommen, nachdem ich die ganzen Löcher in der Doku "überbrückt" hatte.
Der erste Schalter läuft jetzt.

[Haecksler]

Hallo zusammen,
habe einen Schalter der ca. alle 4 Sek.

Code Auswählen Erweitern

CMD_done meldet.
Habe jetzt schon 2,5Mio einträge im LogFile für dieses Jahr.
Habe jetzt mal das

Code Auswählen Erweitern

attr event-on-change-reading gesetzt, das beruhigt zwar den Log, aber das Grundproblem ist dadurch noch nicht behoben.

Hat oder hatte schon jemand das selbe Problem?

Gruß,
Stefan

[frank]

das ist sicherlich nicht normal. sniffe mal den schalter.

event-on-change sollte man trotzdem grundsätzlich für alle readings bei allen devices/channels nutzen, solange man es nicht unbedingt anders benötigt. entlastet fhem.

[Haecksler]

das ist sicherlich nicht normal. sniffe mal den schalter.

event-on-change sollte man trotzdem grundsätzlich für alle readings bei allen devices/channels nutzen, solange man es nicht unbedingt anders benötigt. entlastet fhem.

Hier der Sniff

Code Auswählen Erweitern

2017.04.28 15:02:02.421 0: HMLAN_Parse: HMLAN1 R:E208557   stat:0000 t:13FA0C4D d:FF r:FFC6     m:F5 A410 208557 123451 0604000000
2017.04.28 15:02:02.428 5: CUL_HM Taster_UP_01 protEvent:CMDs_done
2017.04.28 15:02:02.428 5: CUL_HM Taster_UP_01 sent ACK:2
2017.04.28 15:02:04.209 0: HMLAN_Parse: HMLAN1 R:E208557   stat:0000 t:13FA13C0 d:FF r:FFC6     m:F6 A410 208557 123451 0604000000
2017.04.28 15:02:04.217 5: CUL_HM Taster_UP_01 protEvent:CMDs_done
2017.04.28 15:02:04.218 5: CUL_HM Taster_UP_01 sent ACK:2
2017.04.28 15:02:04.911 0: HMLAN_Parse: HMLAN1 R:E208557   stat:0000 t:13FA167E d:FF r:FFC6     m:F7 805E 208557 123451 000000000000000C000000
2017.04.28 15:02:06.903 0: HMLAN_Parse: HMLAN1 R:E208557   stat:0000 t:13FA1E47 d:FF r:FFC6     m:F8 A410 208557 123451 0604000000
2017.04.28 15:02:06.909 5: CUL_HM Taster_UP_01 protEvent:CMDs_done
2017.04.28 15:02:06.910 5: CUL_HM Taster_UP_01 sent ACK:2
2017.04.28 15:02:08.904 0: HMLAN_Parse: HMLAN1 R:E208557   stat:0000 t:13FA2618 d:FF r:FFC6     m:F9 A410 208557 123451 0604000000
2017.04.28 15:02:08.920 5: CUL_HM Taster_UP_01 protEvent:CMDs_done
2017.04.28 15:02:08.921 5: CUL_HM Taster_UP_01 sent ACK:2

Geht endlos weiter...

Gruß,
Stefan

[Wetterhexe]

wollte mal fragen ob jemand die Schalter mit der TSCUL Firmware von Ansgar betreibt?

Ich habe zwei von den Schaltern geflasht, die auch grundsätzlich funktionieren. Aber ich habe reproduzierbare "Hänger" wenn ich zu schnell taste, dann reagieren sie für 10 sec. nicht, manchmal auch länger. Sehr lästig wenn mal mal vom Taster abrutscht oder die falsche Seite erwischt