Philips HUE Modul

traxanos · 20. November 2015 um 08:49

Das wäre mir neu das Module nur Änderungen schreiben sollen. Daher habe ich das bei meinem Modul auch nicht gemacht.

Prinzipiell finde ich das auch nicht besonders schön, aber das nicht schreiben von gleichen Werten müsste dann eine Hauptfunktion des Symcon sein, da ein manueller vorheriger Check nie Threadsafe wäre.

@Nall chan
Du liest hier doch immer mit, wie machst du das? Prüfst du die Werte vorher immer auf Change?

Nall-chan · 20. November 2015 um 11:31

Unterschiedlich.
Es gibt für beide Varianten Vor- und Nachteile.
Somit ist eine generelle Aussage wohl fehl am Platz.

Mal etwas zum Hintergrund:
Egal was Script, Module oder Instanzen in IPS so ‚treiben‘. Jede Änderung und jedes Update eines Objektes (aller Typen!) wird intern in IPS durch eine Nachrichtenschlange gejagt.
Ebenso werden immer alle diese Daten an die aktiven Clients (Console, WebFront, IPSView) übergeben.

Extrem viele und schnelle Änderungen erzeugen also eine deutlich höhere Last innerhalb IPS und auch auf den Clients.
Wer schon mal 500 Objekte gelöscht hat und dann eine Meldung mit ‚MessageBuffer‘ der Console hatte, der hat erlebt wie die Console einfach diese Flut an Meldungen nicht mehr verarbeiten konnte.

Wenn ich mir jetzt überlege das 10-30 Variablen alle 5 Sekunden beschrieben werden… vernachlässigbar

Somit Vorteile/Nachteile u.a. wenn du immer die Werte schreibst:

[ul]
[li]User kann mit einem Event auf aktualisieren Triggern.[/li][li]Je nach Datenmenge höhere Systemlast.[/li][li]Logfile wird je nach Intervall mehr oder weniger gefüllt.[/li][/ul]

Wenn du die Werte nur bei Änderungen schreibst:

[ul]
[li]User kann nicht mit einem Event auf aktualisieren Triggern.[/li][li]User sieht nur Statusänderungen und wenn jetzt lange nichts passiert, sieht er nicht ob überhaupt noch Daten empfangen und verarbeitet werden[/li][/ul]

Bei dem Archiv (Logging) bin ich gerade überfragt, ob es jeden Wert mitschreibt, oder selber noch mal prüft ob es eine Änderung gab. Habe ich noch nicht nachgesehen :o

Ich habe es z.B. bei meinem Homematic-Modul so gelöst, das ich es anhand des Timestamp der Gegenseite (CCU) entscheide ob der Wert neuer (=schreiben) oder älter (= nicht schreiben) ist.
Bei den XBees wird immer geschrieben, da es Events von der Hardware sind, welche der User in der Hardware selbst konfigurieren muss.
Und bei den SqueezeBoxen werden nur Änderungen geschrieben, weil ein Datensatz immer alle Werte (teilweise mehrfach) enthält.
Das dann bei 20-30 Variablen pro Gerät + MediaObjekt (Cover) alle 2 Sekunden; fand ich dann nicht mehr so sinnvoll immer alles zu schreiben.
Außerdem brauche eine Rückmeldung ob der neue Wert sich vom Alten unterscheidet.
Daraus ist das so etwas entstanden:


    private function SetValueBoolean($Ident, $value)
    {
        $id = $this->GetIDForIdent($Ident);
        if (GetValueBoolean($id) <> $value)
        {
            SetValueBoolean($id, $value);
            return true;
        }
        return false;
    }

Probleme mit ThreadSafe habe ich da nicht, da die Empfangsroutine der Daten im Splitter eine Semaphore nutzt. Somit können auch nie zeitgleich Daten in den Geräten empfangen und verarbeitet werden.

Michael

traxanos · 20. November 2015 um 19:59

Also deckt sich das mit dem was ich auch erwartet habe. Ich würde es jetzt erstmal lassen.

Flobo · 21. November 2015 um 09:51

Hi Servus,

habe gerade dein Modul ausprobiert. Leider kommt beim User Registrieren folgende Meldung :
Verwende die aktuelle Windows 4.0 Version

Fonzo · 21. November 2015 um 11:28

Hast Du bevor Du User Registrieren gedrückt hast den Knopf auf der HUE Bridge gedrückt?

egon878 · 25. November 2015 um 16:24

Ich glaube ich habe den Fehler.

Ich hatte ein Backup komplett mit PHP Modulen eingespielt…lief soweit, konnte nur kein Update der Module machen.

Jetzt habe jetzt alle Module mal gelöscht und per IPS Konsole wieder hinzugefügt…siehe da…Module laufen und Update geht auch

janpeterdietz · 8. Dezember 2015 um 23:11

Hallo,

tolles Modul, funktioniert super gut, vielen Dank.

Gibt es auch die Möglichkeit die Lampen langsam zu dimmen, bzw. die Dimmzeit oder Farbwechselzeiten einzustellen?

Gruß
Jan Peter

wibo050447 · 16. Dezember 2015 um 12:48

Hallo traxanos

hab dein HUE Modul installiert funk auf anhieb.

Eine Frage.

Ist geplant die Geofency Funktion zu integrieren oder hab ich da etwas verpasst?

traxanos · 16. Dezember 2015 um 21:50

Was verstehst du unter Geofency im Bezug auf die Bridge?

wibo050447 · 17. Dezember 2015 um 07:43

Hi,

in der APP kannste einen Haken setzten und Geofency aktivieren.

Wenn Du das Haus verlässt können damit alle Leuchten aus- bzw wenn man ankommt eingeschaltet werden.

Die beiden Funktionen wären sehr hilfreich.

Geofency aktivieren
Anwesenheit/Abwesenheit Schaltfunktion ausführen

traxanos · 17. Dezember 2015 um 08:26

das mache ich alles mit meinem abwesenheitsmodul. auch symcon hat ja ein geofancing modul enthalten. und da ich bis jetzt auch nicht wüsste wie ich das integrieren sollte (da ich in der api so nichts finde) werde ich das vorerst nicht integrieren.

aktuell steht ganz klar gruppen noch an erster stelle auf der todo liste.

axelp · 17. Dezember 2015 um 08:34

Geofence braucht man nicht im Hue Modul. Entweder man aktiviert das direkt in der bridge oder baut das über das Geofency Modul in IPS. Alles andere wäre sinnfrei

wibo050447 · 17. Dezember 2015 um 13:22

OK

Danke für die Antwort

janpeterdietz · 20. Dezember 2015 um 11:42

Hallo traxanos

die hue-bridge läuft bei mir hinter einer WLAN Strecke.
IPS 4.0 läuft auf einem Raspberry PI
WLAN wird bei uns von Zeit zu Zeit ausgeschaltet. Nun habe ich festgestellt, dass bei ausgeschlatetem WLAN, (Bridge nicht erreichbar), der Status der Lampen dennoch aktualisiert wird.

Warning: Invalid argument supplied for foreach() in /usr/share/symcon/modules/SymconHUE/HUEBridge/module.php on line 210 
Das Objekt 29222 ist der Timer der Bridge (5 Sekunden).

Warning: Invalid argument supplied for foreach() in /usr/share/symcon/modules/SymconHUE/HUEBridge/module.php on line 210

Ich hoffe du kannst helfen den Absturz von IPS zu vermeiden.
Gruß
Jan Peter

traxanos · 20. Dezember 2015 um 12:43

Hi

ich würde erstmal schauen warum der IPS Abstürzt. Dazu gibt es hier im Forum einen Beitrag wie man mittels GDB den Backtrace ermittelt. -> https://www.symcon.de/forum/threads/27061-Debugging-für-Experten

Unabhängig davon kann ich noch eine Absicherungen einbauen, damit der Foreach-Fehler nicht mehr auftritt. Das wird aber den Crash aber nicht beheben. Ich schätze das es wieder am libcurl liegt.

janpeterdietz · 20. Dezember 2015 um 14:01

Ich habe den GPB aktiviert, ich werde das Ergebnis einstellen sobald ich den Absturz erwischt habe.

Wäre auch prima, wenn die Lampen nicht erreichbar sind (bridge aus) den Status nicht darstellen.
Gerne auch über eine extra Status Meldung.

Gruß
Jan Peter

janpeterdietz · 20. Dezember 2015 um 15:43

Hallo,
anbei die GDP Auswertung:

symcon: …/res/rapidjson/include/rapidjson/document.h:1329: const Ch* rapidjson::GenericValue<Encoding, Allocator>::GetString() const [with Encoding = rapidjson::UTF8<>; Allocator = rapidjson::MemoryPoolAllocator<>; rapidjson::GenericValue<Encoding, Allocator>::Ch = char]: Zusicherung »IsString()« nicht erfüllt.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x632ff440 (LWP 4410)]
0x769248dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0 0x769248dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x7692865c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0x0000013c in ?? ()
#3 0x0000013c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Gruß
Jan Peter

janpeterdietz · 20. Dezember 2015 um 21:20

Hallo nochmal,

nach etwas lesen habe ich folgende lib instaliert: libc6-dbg
Danach hat sich der Trace nach Absturz verändert zu:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x651ff440 (LWP 2664)]
0x769248dc in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
67	../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x769248dc in __GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x7692865c in __GI_abort () at abort.c:92
#2  0x7691d5b0 in __GI___assert_fail (assertion=0xca12ec "IsString()", 
    file=0xc9e47c "../res/rapidjson/include/rapidjson/document.h", 
    line=1990347756, function=<optimized out>) at assert.c:81
#3  0x00021d0c in rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::GetString() const [clone .part.95]
    ()
#4  0x000806d4 in bool rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::Accept<rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>, rapidjson::CrtAllocator>, rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator> >(rapidjson::Writer<rapidjson::GenericStringBuffer<rapidjson::UTF8<char>, rapidjson::CrtAllocator>, rapidjson::UTF8<char>, rapidjson::UTF8<char>, rapidjson::CrtAllocator>&) const ()
#5  0x00721c50 in IPSModule::ApplyChanges() ()
#6  0x0072c578 in IPSPHPModule::ApplyChanges() ()
#7  0x00157908 in EventControl::EventControl(IIPSKernelEx*, unsigned short, IPSBasicModuleInformation)::{lambda()#1}::operator()() const ()
#8  0x0075a398 in IPSTimerPool::processTimers()::{lambda()#1}::operator()() ()
#9  0x76b12848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#10 0x76b12848 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
---Type <return> to continue, or q <return> to quit---
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

traxanos · 20. Dezember 2015 um 22:55

so ich habe das fehlerhandling optimiert. es sollten nun keine fehler mehr im log auftauchen. aber den crash muss sich paresy mal anschauen.

janpeterdietz · 21. Dezember 2015 um 23:20

ein Absturz ist noch nicht aufgetreten, dauert manchmal jedoch länger
Gruß
Jan Peter