LBS 190000608 Zeit aus Logik in ZSU

[vento66]

Dann hab ich die Beschreibung wohl falsch verstanden...
Ich dachte das ein spezifischer Eintrag in der ZSU verändert wird. Also z.B. ZSU 8 hat einen Eintrag für 7:00 (der in der DB die fiktive ID 113 hat).
Dann setze ich E2 auf 113 und kann damit diesen speziellen Eintrag verändern.
Heißt das dann das in der jeweiligen ZSU nur 1 Eintrag vorhanden sein darf?

Du trägst Die ID der ZSU ein. Der LBS schreibt die Zeit von E1 inclusive Offset in die ZSU. Du brauchst da nix machen. Der LBS "merkt" sich die ID die er erstellt hat, und aktualisiert diese. Du kannst auch mehrere Zeiten in die ZSU eintragen. Du brauchst nur für jede Zeit einen eigenen LBS.

[gulp2k]

ok, jetzt hats geklickt

[gulp2k]

vento66
Funktioniert jetzt perfekt bei mir und hat meine ganze Tageszeit abhängige Steuerung erheblich vereinfacht!!

Ein kleines Feedback hätte ich aber da das so aus der Hilfe nicht hervorgeht.
E4/Offset MUSS einen Wert enthalten sonst verhält sich der LBS merkwürdig.
Ich ging zuerst davon aus das leer=0 ist, dem ist aber nicht so.

[vento66]

Freut mich zu hören. Der Wert von E4 wird in der nächsten Version auf Plausibilität geprüft, andernfalls intern auf 0 gesetzt.

[gulp2k]

Hi vento66

ich hab leider immernoch sporadisch ein Problem mit dem LBS...
Ab und zu scheint er sich be der zuordnung der Zeiten zu verhaspeln und dann kommen auch keine Logs mehr.
Ich setzte den LBS bei mir dazu ein die Tageszeiten zu setzten, also "Morgens, Mittages, usw" zum Teil abhängig von Sonnenauf oder Untergang.

Da ich schon bemerkt habe das es zu Problemen kommen kann wenn mehrere LBSe zu schnell hintereinander ausgeführt werden habe ich schon verzögerungen eingebaut.
Hier mal ein Screenshot der Logik und der ZSU, man kann sehen das es nicht passt.
Nur 2 der LBS generieren ein Logfile und genau diese gehen auch ohne Problem so dass ich das nicht poste.

Capture.PNG

Visu:
Capture.PNGCapture.PNG

Könntest du bitte mal drauf schauen?
Besonders Morgens/Noon gehen überhaupt nicht...

Edit: Hatte Logging nur auf 7...
Hier mal das Log aus dem "Noon", werde daraus nicht schlau.

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]874661[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: time offset 0 (3457)[/TD]
 		[/TR]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]875130[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: time E1 with offset 11:30 (3457)[/TD]
 		[/TR]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]875411[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: Datid: 20 (3457)[/TD]
 		[/TR]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]876605[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: time cache 11:30 (3457)[/TD]
 		[/TR]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]877134[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: ID vorhanden 20 (3457)[/TD]
 		[/TR]
[TR]
[TD]2017-10-24 10:18:07[/TD]
 			[TD]877684[/TD]
 			[TD]13206[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000608 [v0.1]: No time change, abort (3457)[/TD]
 		[/TR]
[/TABLE]

[vento66]

Der LBS scheint genau das zu machen, was er soll
Das Log besagt das der LBS getriggert wurde.

• Zeit an E1 11:30 empfangen
• Offset von 0 Minuten, also wird mit 11:30 weitergerechnet
• Die ID der Schaltzeit in der DB ist 20 (brauchen wir für eventuelle updates)
• Die vorherige Schaltzeit aus dem Cachefile ist 11:30
• Die Schaltzeit mit der ID 20 wurde zwischenzeitlich nicht aus der Datenbank entfernt, ist also vorhanden und sollte 11.30 beinhalten
• Da sich nix geändert hat, beendet der LBS hier sein Werk

zsu.PNG Bei mir schaut die Logik auch nicht ganz so verwirrend aus, und funktioniert seit Anfang an.
Hast Du mal eine 1 auf den Reset Eingang geschickt? Dann werden die Cachefiles gelöscht, und wieder neu angelegt.

[gulp2k]

Das heißt der LBS checkt "nur" was in dem Cachefile steht und nicht was tatsächlich im LBS ist?
Weil wie im 2. Screenshot von oben sieht man das der Eintrag mit dem Wert 2(Noon) 18:18 ist und nicht 11:30.
Das gleiche passiert mit dem ersten Eintrag.
Ich hab die Werte nicht per Hand verändert (ZSU ist Read Only in der Visu).
Irgendwann in den Letzten Tagen wurde der Eintrag also verändert und ich kann nicht nach vollziehen wie.

Reset hab ich das letzte mal auch schon gemacht, dann läuft es wieder für eine Weile.
Aber das ist jetzt schon 3 mal passiert, das heißt für mich irgendwo geht was schief.
Leider immer im abstand von mehren Wochen und für mich nicht nachvollziehbar/reproduzierbar.

Hast du eine Idee was ich noch machen könnte um dem auf die Spur zu kommen?

Das einzige was ich bis jetzt sehen konnte ist das es scheinbar nur Morning und Noon betrifft.

[vento66]

Setze mal einen sbc LBS vor den E1 und trigger die Logik öfter. Vielleicht hängt das damit zusammen, das um 0:00 das Edomi interne Datenbank Backup läuft, und die DB dann kurz gesperrt ist.

[gulp2k]

Ich habe ja schon eine Verzögerung um 1h davor, siehe oben links im Screenshot, genau deswegen.
Das erklärt für mich auch nicht wie ein komplett falscher Wert in die ZSU kommt.
Beispiel "Morning", Da steht aktuell 17:18 drin sollte aber eigendlich ein Fixer Wert von 6:30 sein.

Ich beobachte mal weiter.

[gulp2k]

vento66 Hi Micha,

ich hab leider imer noch "komische" Probleme mit dem LBS...
2 Dinge die passieren die eigendlich nicht passieren sollten.
1. Manchmal werden Werte in die Falsche ZSU geschrieben. (Manuelle änderung kann ich ausschließen da ich die ZSU Steuerung extra per PIN geschützt habe)
2. Manchmal scheint er die "Alten" Einträge in der ZSU nicht mehr zu finden und erzeugt neue, das heißt ich bekomme mehrere Einträge die dann nur um ein paar Minuten auseinander liegen.

Ich Tippe darauf das beides zusammen hängt und zwar das der LBS ab und zu die "Falsche" ZSU ID nutzt, dann logischerweise keinen Eintrag mit der "alten" ID findet und einen neuen anlegt. Beim nächstenmal hat er dann wieder die "richtige" ZSU aber die ID des Eintrags passt nicht mehr und er legt dort auch einen neuen an.
Capture.PNG

[gulp2k]

vento66
Hast du noch irgendeine Idee woran das liegen könnte?
Das Problem besteht leider immer noch und ich kann es mir absolut nicht erklären...
Ab und zu scheint er eine falsche ZSU ID zu benutzten und dann zerschießt er mir andere ZSU´s

[vento66]

Da der LBS unter EDOMI 1.55 nicht mehr funktionieren wird, habe ich den LBS aus dem DL entfernt. Wer den LBS nutzt, sollte nicht auf 1.55 updaten, oder den LBS aus seinen Logiken entfernen!

[vento66]

Der neue LBS ist jetzt soweit fertig. Jetzt werden ein paar mutige für den Betatest gesucht. Wenn möglich Testumgebung in einer VM. gulp2k Das Problem mit den ZSU ID konnte ich mittlerweile identifizieren, und hoffentlich beheben.

[gulp2k]

Ich schaus mir bei Gelegenheit nochmals an aber aktuell nutze ich den LBS nicht mehr.

[Janncsi]

Gibt es hier ein Update???