"Ist es Tag"-Variable bei Kerninstanz Location in V4 öfter falsch

Hallo,

ich wundere mich in den letzten Tagen (ein paar Tage Urlaub gehabt :rolleyes: und wetterbedingter Outdoor-Aktivitäten), dass die Außenbeleuchtung am Tage leuchtet. Im Schaltscript wird die Variable „Ist es Tag“ der Kerninstanz Location gelesen. Das Licht wird nur bei „False“ UND gleichzeitiger Bewegung geschaltet.

Die Variable ist am Tag auch auf false, auch über einen Tageswechsel hinweg, obwohl die Zeitstempel der Werte aktualisiert scheinen.

Zwar kann ich per zyklischem Script ein

IPS_ApplyChanges(58898 /*[Location]*/);

setzen, aber das sollte doch auch out of the box gehen.

Hat jemand von euch damit auch Sorgen? Oder ist es sogar ein Bug? Problem besteht erst nach dem letzten Update (24.04.2016, 05c0d71ac1c5)?

Was hast du denn in der Konfiguration vom Location Control angegeben? (Ich würde dann versuchen das Problem nachzustellen)
Wir haben an der Stelle in den letzten Updates nichts verändert gehabt.

paresy

Eingestellt sind die Koordinaten und als Definition für Tag / Nacht „Sunrise“ / „Sunset“. Hat ja bis zum letzten Update unauffällig funktioniert. Mag sein, dass der Zeitrahmen Zufall ist. Hatte vorhin noch gesehen, dass der Sonnenaufgang hing. Also gleiches Datum wie Sonnenuntergang (auf die Zeit habe ich nicht geachtet). Daher dann auch Nacht.

Ich lasse das jetzt noch mal 1-2 Tage auf „Sunrise“ / „Sunset“. Tritt des Phänomen erneut auf, stelle ich wieder auf „Civil twilight“ zurück. Vielleicht liegt da das Problem.

Eben noch aufgefallen, dass die Zeiten wieder falsch sind -> Screeshot

Das kann ich so in der Art auch bestätigen. Bei mir verhält es sich auch seltsam, wenn ich beispielsweise Lampen Einschalte wenn IstTag = FALSE ist, schaltet sich die Lampe auch an. Per Zeit gesteuerten Event geht die Lampe um 1 Uhr Nachts auch wieder aus. Lustig ist, dass irgendwann Morgens die Lampe wieder eingeschaltet wird -> auch der Timestamp der letzten Änderung von IstTag ist auf irgendwann Morgens (nicht die Uhrzeit wo der eigentliche Tag/Nachtwechsel stattfinden sollte) geändert worden. Eigentlich hätte sich die Lampe nicht einschalten dürfen weil die Bedingung IstTag = false nicht erfüllt ist, da IstTag = true gesetzt ist.

Kann es sein, dass die Variable kurz zu flappen (schneller Statuswechsel hintereinander) beginnt wenn sie aktualisiert wird? Das würde meine Beobachtungen erklären.

P.S. steht bei mir ebenfalls auf Sunrise / Sunset.

Also mir ist aufgefallen, das die Variable wohl nach Updates sich nicht korrekt aktualisiert… können aber auch zeitlich Zufälle gewesen sein das es immer nach einem Update nicht ging…

Heute diese Beobachtung unten. Es scheint sich nunmehr nichts zu aktualisieren (zuletzt 09.05. 19:32) Habe auch nichts gefunden, wo man es ausschalten kann. Das Modul „macht die Nacht zum Tag“ :D. In der Hilfe zum Location Control steht zur Aktualisierung:

Die Dämmerungswerte bestimmen auch den Zeitpunkt der Neuberechnung. Das heißt, dass beim Erreichen des Zeitpunkts für den Sonnenaufgang, der neue Wert für den nächsten Sonnenaufgang berechnet wird.

Das sieht in der Tat völlig falsch aus. Magst du mir, sobald der Fehler wieder zuschlägt, noch ein Bild von den „Timer Informationen“ machen? Die findest du auf der Willkommensseite unter „Spezialansicht hinzufügen“.

paresy

Gleiches Problem hier, Timer Information angehängt.

Mfg
Thifi

Mich hat es heute früh auch erwischt, laut iOS ist es immer noch Nacht …
Dadurch brannte mein Aussenlicht heute früh…

Lördy

Da ich von meinem Test Raspi IPS ebenfalls die Astronomischen Ereignisse verwende… bin ich heute ebenfalls über den Fehler gestolpert.

Bei mir ist es jetzt „NACHT“. Abruf zuletzt vor 10 Minuten. Auch die sonstigen Werte sind stehen geblieben.

Ich bin dann in „Location“ rein, hab dort eines der Dropdown fehler (Day (Start)) ausgewählt.
Dort auf den bereits hinterlegten WErt geklickt (bei mir Civil Twilight) - Übernehmen.
Und schon wurde die neuen Werte inkl. das es Tag ist gesetzt.

Was die Raspi IPS Version angeht, habe ich eine ganz ganz alte 4.00 (Mind. 6 Monate alt!).

Das selbe Problem ist in der aktuellen „Tester“-Version.
Gruß,
Peter

Gesendet von iPhone mit Tapatalk

Heute Abend wurde die Variable „Ist es Tag“ wieder nicht umgestellt.
Dadurch fuhren keine Rolläden runter und Aussenbeleuchtung blieb aus.

Lördy

Bei mir genau so seit gestern.
Ich habe kurz versucht dem Problem auf den Grund zu gehen.
Dabei ist aufgefallen, dass beim Raspi die Zeitaktualisierung nicht mehr passt.
Wenn ich die Zeiteinstellungen mit „raspi-config“ anpassen wollte kam auch irgend eine Fehlermeldung, Zeit hat sich jedoch einstellen lassen.
Wenn ich später von der Arbeit wieder Zuhause bin, werde ich das nochmals genau anschauen und berichten.

Also, bei mir kam beim Versuch die Zeiteinstellungen mit „raspi-config“ anzupassen folgende Meldung:
locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder Verzeichnis nicht gefunden

Habe die Zeit trotzdem stellen können.
Anschließend hat auch wieder alles funktioniert.

Klar, wenn die Zeit des raspi nicht mehr funktioniert, kann Location-Modul keinen Zeitvergleich mehr durchführen und dadurch auch die Zeit nicht aktualisieren.

…bei mir mit der aktuellen Test-Version auf der Symbox auch so.
Sollte also nicht zwingend am RPI liegen.

Immer noch der gleiche Stand wie im Screenshot in Post 6: „Ist es Tag“-Variable bei Kerninstanz Location in V4 öfter falsch

Habt ihr den Dienst mal neustartet? Ist es dann vorerst weg? Ich möchte noch warten, falls paresy noch Daten braucht von der „Nachtschicht“.

Nachtrag: Timer Informatinen von der Location

Sowohl Dienst und ganze Symbox neugestartet.
Ohne Erfolg :frowning:

Loerdy

Also bei mir war es grade NACHT ob wohl es Tag ist.
Ich hatte mal mitgeloggt, heute war keine Variablenänderung zu sehen, d.h. er hat einfach nicht auf Tag geswitcht…
Nach Neustart des Dienstes ging er dann automatisch auf TAG.

Bei mir hats heute wieder geklappt. Wie in Post #10 getestet hat es gestern Abend und heute morgen funktioniert. Mal schauen wie lange…

Gesendet von meinem Redmi Note 2 mit Tapatalk

Das Problem scheint in der Tat bisher nur den 11.05/12.05 betroffen zu haben. Nach einem Dienst neustart läuft die Aktualisierung auch wieder korrekt. Ich weiß bisher noch nicht warum es an den beiden Tagen zum Problem kam, aber es betrifft auf jeden Fall alle Betriebssysteme. Ich melde mich noch mal, sobald ich mehr Informationen habe.

paresy

paresy:

Das Problem scheint in der Tat bisher nur den 11.05/12.05 betroffen zu haben.

kann ich nicht bestätigen. Bei mir hängt die Instanz immer noch schon seit dem 09/10.05.16 fest. Habe auch mal den Dienst gestartet - im Moment wurden richtige Werte esetzt.