Hi JD,
ich habe mich auch mit der HUE Emulation als Verbindung befasst.
Mein Problem ist, sobald der RPI neu startet (Stromausfall etc.), verliere ich die Bridge im f@h und muss mich mühselig via discovery spielen damit ich sie wieder finde.
Hast du ein ähnliches Problem ?
Bzw. wie hast du die COnfig der Emulation eigestellt ?
Momentan finde ich auch die Briidge nicht mehr im f@h, egal welche Einstellungen der COnfig ich mache...
Lg Stephan
Hast du ein ähnliches Problem ?
Nein, nach einem Neustart meines Windows Servers bzw. openHAB Dienstes kann es zwar ab und an einige Zeit dauern, bis alle 'Lampen' von f@h wieder korrekt erkannt werden.
Spätestens nach einem Update im openHAB (also z. B. fake Lampe wurde ein-/ausgeschaltet) gibt sich auch das wieder.
Aber die Verbindung zur 'Bridge' blieb bisher stets stabil bestehen. Musste nie neu in f@h eingebunden werden o.Ä.
Arbeitest Du mit fixer IP für Raspi, oder DHCP? Bei mir ist openHAB IP fix (als auch SysAP)?
Bzw. wie hast du die COnfig der Emulation eigestellt ?
Alles auf Default belassen.
Momentan finde ich auch die Briidge nicht mehr im f@h, egal welche Einstellungen der COnfig ich mache...
Wurde bei mir direkt gefunden & verbunden, musste nie neu suchen.
Am ehesten tippe ich auf Netzwerk Probleme, Firewall etc.
Neu gestartet (SysAP und Raspi bzw. openHAB Daemon bzw. HUEEmulation) hast Du ja bereits?!
Nein habe beide (Openhab + SysAP) auf DHCP, eventuell ist dies der Fehler bei einen Neustart.
Werde Schritt für Schritt meine Installation umstellen (habe auch ein paar Shellys, Switches etc. auf DHCP), denn hilft es nicht so schadet es auch nicht 😉
Habe nun die Bridge auch wieder gefunden, ein neuer Name der Bridge in der OH Config war die Lösung.
Ebenfalls habe ich alle Fehlermeldungen der Emulation im OH Log weggebracht.
Jetzt bin ich mal gespannt wie lange das so bleibt ...
Danke vorerst für deine Infos.
Beste Grüße
denn hilft es nicht so schadet es auch nicht
Nein, ich habe bereits des Öfteren die Erfahrung gemacht das für "zentrale" Geräte oft fixe IPs (vor allem out-of-DHCP-Range) das Leben vereinfachen 😉
So habe ich auch z. B. die "echten" HUE-Bridges jeweils mit fester & leicht zu merkender IP ausgestattet.
Auch damit keine Probleme bzgl. f@h Integration, Bridges wurden 1x eingebunden und sind seither "da".
Habe nun die Bridge auch wieder gefunden, ein neuer Name der Bridge in der OH Config war die Lösung.
Wertvoller Hinweis, thx. 🙂
Hallo zusammen,
ich habe etwa vor einem halben Jahr OpenHab 2.5.11 im Qnap Docker installiert und nutze die HUE Emulation um Free@Home Variablen zur Verfügung zu stellen und um Informationen zwischen OpenHab und Free@Home zu übertragen. Das ganze hat jetzt ein halbes Jahr perfekt funktioniert. Keine Schaltverzögerungen wie ich es bei der HA-Bridge hatte. Absolut zuverlässig. Ich war echt happy mit der Lösung. Gut ich habe ein halbes Jahr kein Update gemacht, weder Qnap, noch Free@Home.
Jetzt wollte ich vor kurzem eine weitere Funktion implementieren und dachte mir ich traue mich mal und führe alle updates durch. Qnap , Container station (wo der OpenHab Docker läuft) und Free@Home auf die neuste Version.
Danach haben die Probleme begonnen. Free@Home bringt die Meldung das meine Hue Emulationen nicht mehr reagieren.
Was ich schon gemacht habe:
1.
-Openhab Emulation ID Name in der Config geändert . Also letzte Zahl in der Hoffnung das alles wieder neu erkannt wird.
Jedoch findet Free@Home die Hue Emulation dann gar nicht mehr, also habe ich es wieder zurück geändert. Danach findet er Die Hue Emulation zwar wieder aber die Lampen haben immer noch nicht reagiert.
2.
Ein paar Tage später hat Free@Home dann, wie durch ein Wunder wieder alle Lampen erkannt und hat auch den korrekten prozentuellen Lampenstatus von OpenHab erhalten wenn ich diesen in der OpenHab App gerändert habe. Heute wollte ich wieder alle Free@Home Aktionen in der Browseroberfläche aktivieren welche die HUE Emulationen benutzen. Gleich die erste Lampe hat nicht reagiert. Nach kurzer Zeit wurden wieder alle Lampen auf "Reagieren nicht gesetzt".
Hat jemand ähnliche Erfahrungen gemacht? Mit der neusten Free@Home Software z.b ?
Es war auf jeden Fall ein Fehler alle Updates gleichzeitig zu machen. Ist mir eine Lehre für die Zukunft.
Hat jemand ähnliche Erfahrungen gemacht? Mit der neusten Free@Home Software z.b ?
Nach dem Update auf 2.6.3 hat mit OpenHAB 2.5.7 zunächst alles funktioniert.
Nach 1-2 Neustarts des SysAP (wegen der kühlen Probleme, s. Anderer thread) leider nicht mehr, alle 'HUE Aktoren' offline.
Habe die HUE Emulation gelöscht und neu gekoppelt (musste dazu kurz Firewall deaktivieren, OpenHAB läuft unter Windows bei mir, sonst kommt Discovery nicht 'durch')
-> jetzt tut wieder alles ? ?
@jd Hallo JD,
ich habe jetzt nochmal die ID der Bridge in der OpenHab Config geändert.
Über Nacht hat Free@Home jetzt die neue Bridge erkannt und nach dem koppeln auch alle Lampen mit neuer Nummer.
Ich habe jetzt zum Test die Konfiguration einer Lampe auf eine neu erkannte übertragen.
Leider kein Unterschied zu dem Verhalten zuvor.
Wenn ich den Status in der Openhab App ändere wird er in Free@Home angezeigt --> OK
Wenn ich den Status in Free@Home ändere bleibt er in Openhab unverändert --> NOK
Daraufhin habe ich den Log aufgezeichnet. Sieht der bei dir genauso aus? Bzw schickt Free@Home den korrekte Befehl "AbsoluteSetValueControl[0x0011] ?
Sieht der bei dir genauso aus? Bzw schickt Free@Home den korrekte Befehl "AbsoluteSetValueControl[0x0011] ?
f@h schickt in meinem Fall nur "SwitchOnOff" 1/0 zu openHAB (2.5.7).
Klappt problemlos, Status wird in openHAB korrekt übernommen.
Mache ich allerdings quasi nie / verwende ich nicht - ich brauche eig. nur Status VON openHAB in f@h...