Missing Ack & disconnected bei HMLAN - Änderung in 00_HMLAN.pm erforderlich?

[dougie]

...ir ist noch was aufgefallen:

Ich hab mir ein Skript gebastelt, das um 23:59 5 Messungen durchführen soll.
Da diese Messungen im Abstand von 6 Sekunden erfolgen, hab ich fhem einfach mit fhem ("sleep 6")
schlafen gelegt.

Nach den 5 * 6 = 30 Sekunden bekomme ich jedes Mal ein

Code Auswählen Erweitern

2013.01.28 23:59:30 1: 192.168.1.27:1000 disconnected, waiting to reappear
2013.01.28 23:59:35 1: 192.168.1.27:1000 reappeared (HMLAN_Casa)

Vergewaltige ich mit dem Sleep Befehl fhem oder stolpert hier HMLAN?

VG
Ralf

[martinp876]

wenn du FHEM schlafen legst schäft es - komplett. Dann wird GARNCHTS mehr gearbeitet (gesunder tiefschlaf). Unter anderen wird HMLAN nicht mehr getriggert. Das fällt nach 35 sec mit sicherheit aus. Evtl auch schon nach 6 sec.

Du solltest mit timern arbeiten - sleep ist in einem single-threated system denkbar ungeeignet. Auf Anwenderlevel meiner Meinung nach garnicht

[Dennis D.]

Hallo spunky78

um festzustellen wo das Prolem liegt muessen wir auf die IO-ebene runter gehen. Da mit es nicht zu viele traces gibt sollte man

attr global verbose 1
attr global mseclog 1
attr <iodev> loglevel 1
attr <iodev> hmProtocolEvents 0

setzen
die Logs werden dann ins 'zentrale' fhemlog geschrieben. Hier habe ich dann den Ablauf mit timing

Gruss
Martin

Hi Martin,

also ich habe nun mal ausprobiert, die fünf Aktoren nacheinander zu schalten, anstelle alle gleichzeitig:

Code Auswählen Erweitern


define Jalousie_hoch at *{sunrise("HORIZON=-5",0,"06:00","09:00")} {\
if (Value("FL_KeyMatic") ne "locked") { fhem ("set WZ_Jalousie rauf ;; define EZ_J_verz_ra at +00:00:01 set EZ_Jalousie rauf ;; define KU_J_verz_ra at +00:00:02 set KU_Jalousie rauf ;; define HA_J_verz_ra at +00:00:03 set HA_Jalousie rauf ;; define VR_J_verz_ra at +00:00:04 set VR_Jalousie rauf")}}


Im Gegensatz zu der Variante, wo ich alle gleichzeitig hab schalten lassen und bei der die VR_Jalousie fast immer einen "Missing Ack" lieferte, habe ich mit dem nacheinander geschalteten Aktoren gar keine "Missing Ack" mehr und alles läuft seit über ner Woche einwandfrei.

Gleiches hatte ich mit zwei UP-Lichtschalter. Bei gleichzeitiger Ansteuerung, lieferte der zweite fast immer ein "Missing Ack". Nach der Umstellung auf eine verzögerte Schaltung mittels "define at" gibts auch hier keine "Missing Ack" mehr.

Gruß,
Dennis

[martinp876]

Hallo Dennis,

danke für die Info. Den burst zu entzerren ist immer eine gute Idee.

ich habe den resend jetzt etwas dynamisch verzögert statt starr 1 sec etwas zwischen 1-5 sec.
Für einen TC sind wir sowieso zu langsam - und für schalter sollte es die Lage verbessern.

Gruss
Martin

[dougie]

wenn du FHEM schlafen legst schäft es - komplett. Dann wird GARNCHTS mehr gearbeitet (gesunder tiefschlaf). Unter anderen wird HMLAN nicht mehr getriggert. Das fällt nach 35 sec mit sicherheit aus. Evtl auch schon nach 6 sec.

Du solltest mit timern arbeiten - sleep ist in einem single-threated system denkbar ungeeignet. Auf Anwenderlevel meiner Meinung nach garnicht

Ein SEHR wertvoller Hinweis! Danke Martin. Die Begriffe "single-threaded" und "Tiefschlaf" waren mir baislang nicht bewusst. Hab's umgestellt und funktioniert prächtig.

VG
Ralf