philips hue modul

[justme1968]

weil es in dem thread darum ging das bei fehlendem shutdown auf fhem seite dort irgendetwas im kernel nicht freigegeben wird. das ist auch nur eine idee ohne beleg.

die 5 Minuten sind eigentlich schon immer der default 

[Loredo]

weil es in dem thread darum ging das bei fehlendem shutdown auf fhem seite dort irgendetwas im kernel nicht freigegeben wird. das ist auch nur eine idee ohne beleg.

Offenbar hätte ich alles lesen sollen, aber ich fühlte mich dort direkt so daran erinnert.
Ich kenne ähnliche Phänomene nämlich auch von er Entwicklung des ENIGMA2 Moduls.

Ist nur eine Vermutung, aber den Socket per Shutdown explizit zu schließen klingt zwar erstmal logisch, aber wenn die Gegenseite das eigentlich lieber selbst handhaben möchte, bringt es die Bridge ggf. irgendwann in einen inkonsistenten Zustand. Ggf. erwartet der Webserver auch nicht einfach nur das Schließen der TCP Verbindung, sondern vorher noch was auf HTTP Ebene.
Vielleicht würde es helfen sich den Traffic zwischen der Philips App und der Bridge einmal mit Wireshark anzuschauen und mit dem Traffic von FHEM zu vergleichen? Zugegeben da gehen wir schon sehr weit runter... ansonsten könnte man auch mal schauen, wie der Webserver bei FreeRTOS so grundsätzlich arbeitet

[justme1968]

prinzipiell muss ein socket auf beiden Seiten geschlossen werden. die beiden Enden sind ja in so fern unabhängig das es zwei verschiedene systeme sind und auf der empfangenden seite immer noch gelesen werden kann was noch im socket ist auch nach dem die sendende seite zu gemacht hat.

mit wireshark könnte man vielleicht sehen ob auf unterster ebene nach geantwortet wird.

gefühlsmäßig würde ich aber sagen das mit variieren des pooling Intervalls auf 1/10 und das 10 fache schnell zu sehen sein sollte welchen Einfluss es auf die Stabilität hat.

[Loredo]

gefühlsmäßig würde ich aber sagen das mit variieren des pooling Intervalls auf 1/10 und das 10 fache schnell zu sehen sein sollte welchen Einfluss es auf die Stabilität hat.

Jaein, zumindest für mich ließe das keine großen Rückschlüsse zu, vielleicht kannst du mir das besser erklären?
Ich müsste ja zunächst einmal sicher wissen, dass der Fehler immer nach einer bestimmten Zeit auftritt. Wenn ich das Interval dann verlängere, dann tritt es entweder äquivalent dazu entsprechend erst später auf oder eben gar nicht mehr. Mit dem Fall "gar nicht mehr" könnte ich aber nicht leben, weil ich den Status der Lampen nicht erst 30 Minuten später wissen will (überspitzt gesagt). Die Erkenntnis, dass man bei längeren Intervallen den Fehler u.U. vermeidet oder nur herauszögert, hilft also bei der Eingrenzung des Fehlers meiner Meinung nach nicht.


Was würde dir das Ergebnis denn mehr sagen? Ich will mich ja nicht generell weigern, es ist eben nur so, dass die Fehleranalyse damit vermutlich Tage oder Wochen brauchen würde. Rein deshalb, weil die Bridge dann erst in 2 oder 3 Wochen das nächste Mal stehen bleibt. Ich habe die andere Bridge aktuell noch in dem nicht funktionierenden Status, weil ich gleich erst hinfahre, um sie neu zu booten.

[justme1968]

die idee ist rauszufinden ob und wie das hängen bleiben mit dem pollen korreliert. wenn es bei 1/10 so langem oder 1/20 so langem intervall immer noch mehrere tage dauert würde ich sagen es liegt nicht am pollen an sich weil es dann eigentlich innerhalb weniger stunden passieren müsste.

ich weiss das ist alles nicht wirklich produktiv aber ich habe leider gerade keine bessere idee. wenn das ganze nicht halbes reproduzierbar ist wird es sehr schwer rauszufinden woran es liegt.

es geht also nicht ums hinauszögern sondern ums rausfinden ob das eine überhaupt mit dem anderen zu tun hat.

[Loredo]

die idee ist rauszufinden ob und wie das hängen bleiben mit dem pollen korreliert. wenn es bei 1/10 so langem oder 1/20 so langem intervall immer noch mehrere tage dauert würde ich sagen es liegt nicht am pollen an sich weil es dann eigentlich innerhalb weniger stunden passieren müsste.

ich weiss das ist alles nicht wirklich produktiv aber ich habe leider gerade keine bessere idee. wenn das ganze nicht halbes reproduzierbar ist wird es sehr schwer rauszufinden woran es liegt.

es geht also nicht ums hinauszögern sondern ums rausfinden ob das eine überhaupt mit dem anderen zu tun hat.

Ok, dann hab ich dich teilweise falsch verstanden. Ich dachte, ich solle das Interval LÄNGER stellen. Da ich es seit gestern von 300 auf 75 Sekunden reduziert habe, schauen wir mal, ob jetzt was passiert oder nicht.


Gruß
Julian

[JoMe]

Hallo,

ich versuche seit ein paar Tagen die Philips Bridge in Fhem einzubinden....und bin am verzweifeln....

ich bekomme immer, nach dem ich die Bridge, wie in der Doku beschrieben, in meiner FHEM.cfg eingetragen habe.....

"unauthorized user"......

und jedes mal einen key, ohne das ich die Taste an der Bridge gedrückt habe.......

Gibt es da einen Tip??? Oder was mache ich falsch?


Gruß aus Berlin,

Joachim

[justme1968]

zuerst die bridge anlegen. der STATE sollte pairing sein und es sollte ein key angelegt werden. danach den knopf an der bridge drücken. der state sollte wechseln. jetzt mit save speichern.

gruss
  andre

[JoMe]

Hallo,

danke für die schnelle Antwort...

da kommt leider kein "pairing" sondern gleich "unauthorized user"...im STATE..

Habe es gerade noch mal versucht..

fhem.cfg
define bridge HUEBridge 192.168.xxx.xxx
attr bridge room 11_System
attr bridge verbose 5

direkt nach dem Speichern habe ich folgendes in der "Bridge"


Internals
DEF                 192.168.xxx.xxx
Host                192.168.xxx.xxx
INTERVAL        300
NAME              bridge
NR                  16
NTFY_ORDER   50-bridge
STATE             unauthorized user
TYPE               HUEBridge
mac                xx:xx:xx:xx:xx:xx
name              Philips hue
swversion        01009914

in attr bridge key steht auch schon was.....und das ändert sich auch nicht, wenn ich die Taste drücke....

gruß,

Joachim

[justme1968]

der key wird von fhem vorgegeben. der soll sich auch nicht ändern.

die firmware version ist neuer als die die aktuell zum update bereit steht. ist die bridge neu?

ich muss mal schauen ob ich dein problem nachstellen kann.

gruss
  andre

[JoMe]

Hallo,

letzte Woche gekauft...und heute war ein Update für die Bridge da.....


Dank dir....

Gruß,

Joachim

[justme1968]

was bekommst du wenn du im browser die url aufrufst:

Code Auswählen Erweitern

http://<deine bridge>/api/config?
und was bei dieser:

Code Auswählen Erweitern

http://<deine bridge>/api/<key>/config?

jeweils die ip bzw. den key aus fhem eintragen.

gruss
  andre

[justme1968]

mit der neuen firmware verhält sich die bridge etwas anders. ich hab das modul eben angepasst. das update ist dann morgen da.

wenn du nicht so lange warten willst kannst du in zeile 134

Code Auswählen Erweitern

if( !defined($result->{'mac'}) ) in

Code Auswählen Erweitern

if( !defined($result->{'linkbutton'}) )ändern.

und dann mit 'reload 30_HUEBridge.pm' das modul neu laden und das device mit modify ändern oder neu anlegen oder einfach fhem neu starten.

gruss
  andre

[JoMe]

Guten morgen,

Vielen dank, werde ich nachher gleich versuchen......

Gruß
Joachim


Sent from my iPhone using Tapatalk

[der-Lolo]

Guten Morgen Andre,
bereits gestern abend bemerkte ich eine unregelmässigkeit - zwei meiner Bulbs liesen sich nicht mehr über FHEM schalten, die weisse runde fernbedienung funktionierte einwandfrei. aber von Fhem aus wurden die Bulbs weder durch notifys noch durch die standard on off und toggle buttons geschaltet.
ich trennte heute morgen die beiden Bulbs kurz vom Netz - danach funktionierte wieder alles einwandfrei...

Mich stört das jetzt nicht grossartig, aber ich dachte ich gebe Dir mal eine Info.
Gruss aus Berlin,
Michael