ich würde die Frage dennoch anders stellen: Hat der User ein Tradfri-Gateway, dann muss dieses genutzt werden um es und die damit verbundenen Geräte - wie auch immer - ins IP-Symcon zu bekommen.
Das es dort auch andere Möglichkeiten gibt die Geräte zu benutzen setzt doch voraus das der Nutzer das auch gemacht hat.
Hier ist aber die manuelle Installation einer zusätzlichen Software erforderlich (siehe Seite 1 dieses Threads) und eine weitere Einschränkung: es funktioniert m.W. nur auf Linux-Systemen…
Du meinst also, daß Deine Lösung für tradfri direkt gemacht ist,
da es aber ZigBee ist, müßte es auch in HUE gehen.
Ist ja bei Osram auch so.
Aber das Problem ist eben, daß kaum ein Anwender in dem Verkaufstheater mehr klar kommt. Während des Buch-Schreibens
habe ich weiter Bussysteme eingekauft, die ich noch nicht hatte. Bei Hornbach in Rostock habe ich u.a. Homematic IP für 20
Euro gekauft (2 Stellantriebe + Schnittstelle), darunter auch etwas Bosch, HUE und Osram. Ich habe dann die Verkäufer (wie
üblich) gefragt, warum es denn kein Gateway für Osram gäbe. Da sagte der Verkäufer, daß er es nicht vorrätig hätte. Eine Woche
später habe ich dann die gleiche Frage bei Conrad Dortmund gestellt. Der Verkäufer lachte mich fast aus und stellte fest, daß
das Osram-Gateway so fehlerhaft wäre, daß niemand es kaufen würde und er es nicht mehr anbieten würde. Das geht doch alles
mit HUE war seine entrüstete Antwort.
Dieses nur kleine Beispiel sagt alles.
Daher kommen auch meine Fragen an Kai, warum es MQTT, DeConZ, usw. gibt.
ich habe nur 2 Lampen und das Gateway, da ist dieses Modul super praktisch. Allerdings habe ich das Phänomen, dass ich eine der beiden Lampen nicht über den Status ein/ausschalten kann. Wenn ich sie im webfront anklicken springt der Status sofort wieder zurück. Über den Dimmwert kann ich sie steuern. Beide Lampen sind identisch, alles auf aktueller Firmware. Ich hab die Lampe auch schon mal zurückgesetzt. Hat jemand vielleicht eine Idee?
Ich bin gerade mal in der Config Instanz auf Konfigurieren bei der Lampe, als ich dort im Testbereich mal schalten wollte kam folgende Meldung als Popup:
Ich hatte zuerst die aktuelle 5.5, dort war es schon.
Aktuell bin ich auf der letzten Testing vom 6.0
Was mir noch aufgefallen ist, bei einigen aktionen dauert es ewig bis die Konsole fertig geladen hat.
Wenn ich z.B. in die Config Instanz gehe lädt er ewig und zeigt dann manchmal auch nichts an.
OK, ich hab die Lampe jetzt (noch mal) gelöscht und neu angelegt. Jetzt geht es, hoffe mal es bleibt dabei.
leider zicken meine Tradfri wieder, ich kann sie zwar im WebFront schalten aber es passiert nix
Ich kann auch in keinem Debug irgendeine komische Meldung finden, einzig der IPS2Tradfriconfigurator braucht gefühlt ewig (1min?) zum laden und ist dann leer.
Gibt es noch Logs die ich durchsuchen kann?
Danke.
Grüße
Rolf
Edith sagt:
Eben gerade (obwohl es schon seit > 1h nicht geht) kam die Meldung im Debug des configurator debug das keine Verbindung zum Gateway hergestellt werden kann und noch eine andere Meldung die ganz schnell verschwunden ist weil dann im Sekundentak diese Meldung gefeuert wurde:
Außerdem kam ganz kurz auch mal irgendwas in der oberen Ecke der Instanzkonfiguration das der Key oder so ungültig ist, ist aber auch wieder verschwunden.
Bin dann mal auf Zugangsaten erzeugen mit einem neuen Schlüsselwort, erst ist nix passiert.
Danach sind die Lampen auf einmal ganz schnell wieder gefunden worden. Seit dem ist im Debug der Lampe auch die Hölle los, vorher war da eher nix. Jetzt lassen sie sich auch wieder Steuern und aktualiseren den Status wenn ich mit der Remote schalte. Achja, der alte Schlüssel steht aber noch immer in der Instanzkonfig,…
inzwischen hab ich rausgefunden, dass sich das Gateway immer aufgehängt hatte wenn die Steuerung nicht mehr reagiert. Allerdings lässt sich das nicht so leicht erkennen.
Ich habe das Gateway und alles andere noch mal komplett zurückgesetzt aber ohne Besserung.
Daher habe ich symcon abgeschaltet, jetzt läuft das Gateway seit 2 tagen stabil
Vorher hatte ich es mehrere Monate mit openhab stabil am laufen. Es muss also am symcon Modul liegen, ich hab aber keine Idee wo ich suchen soll,…
vielleicht zum Verständnis: Das Modul kommuniziert immer nur mit dem Gateway. Weil keine Statusmeldungen vom Gateway gesendet werden, muss gepollt werden. Wie mir bestätigt wurde ist das auch in der App so.
Ich bin sowieso nicht so ein Fan von all diesen Funksystemen, empfinde auch dieses als unzuverlässig.
Wenn es irgendwelche konkreteren Fehlermeldungen gibt, die mir helfen würden einen Fehler im Modul zu korrigieren so werde ich das dann gerne auch machen, so sind mir da ein wenig die Hände gebunden…
bitte meine Post nicht als Kritik am Modul verstehen, ich find es absolut Toll das du es geschrieben hast! Ich versuche nur (ziemlich hilflos) das Verhalten bei mir zu beschreiben, da ich noch recht neu im Umgang mit Symcon bin.
Gibt es vielleicht noch andere Logfiles? Oder die Möglichkeit das Loglevel irgendwo zu erhöhen? Oder kann man vielleicht das polling runter schrauben? Wenn du noch irgendeine Idee hast wie ich bei der Fehlersuche weiter kommen kann wäre ich Dankbar!
Hej Joachim,
vielen Dank für deintolles Modul.
Ich habe bei mir leider das selbe Problem was Rolf oben beschrieben hat.
Wenn ich die Gateway neu Starte läuft sie ein bis 2 Stunden stabil.
Danach ist sie weder über die App noch über die symcon zu erreichen.
Zwieschendurch taucht sie dann immer wieder auf.
Schalte ich das Modul ab, läuft die Gateway tagelang durch ohne Probleme.
In dem moment wo ich das Modul wieder einschalte tritt nach einer gewissen zeit das o.g. problem wieder auf.
Zudem ist mir noch folgendes aufgefallen.
Das Problem scheint nur zu bestehen solange die Gateway mit der App und der Symcon verbunden ist. Trenne ich die App von der Gateway läuft alles Problemlos. Allerdings kann ich die App mit der Gateway im anschluss nicht mehr verbinden. Da kommt dann immer die Fehlermeldung das die App die Gateway nicht erreichen kann. Schalte ich nun das Symcon modul aus kann ich sofort die App wieder verbinden.
Das ganze fühlt sich so an als wenn die Kommunikation zur Gateway zu viel wäre und sie überlastet.
Vielleicht hilft Dir das ganze ja bei der Fehleranalyse.