Hallo liebes CA-Team,
ist geplant virtuelle Geräte nativ in homee zu implementieren, ohne Umweg über Homeean, wäre ein cooles feature.
SG
Philipp
Hallo liebes CA-Team,
ist geplant virtuelle Geräte nativ in homee zu implementieren, ohne Umweg über Homeean, wäre ein cooles feature.
SG
Philipp
Die überlegen noch! Allerdings schon 2016!
Nein, davon ist nichts bekannt. Alle Infos stehen hier:
@sublevel7: Falls Du noch Bedarf an einer MQTT-Einbindung für den HM-WDS40-TH-I hast, ich habe den heute in homeeup “zum Laufen” gebracht.
Ich übernehme damit jetzt die Temperatur- und Luftfeuchtigkeitswerte von 433MHz-Sensoren über MQTT / homeeup in homee.
Ja, Ja, Ja
Ja, ein Fork des Forks
egal wer es macht , Hauptsache es geht weiter.
Bei mir läuft homeeup auf einem Raspberry. Unter homee konnte ich das virtuelle HomeMatic Gateway problemlos finden und einbinden. Das Hinzufügen von vier CMD-Switches hat auch ohne Weiteres funktioniert. Schaltung und Rückkopplung laufen ebenso fehlerfrei.
Die CMD-Switches steuern meinen Harmony Hub über die Harmony API, die ich auch über homeean installiert habe.
Leider kommt es in unregelmäßigen Abständen dazu, dass die “Geräte” nicht verfügbar und ausgegraut sind. Sie lassen sich nicht schalten und auch die Statusanzeige ist dann nicht korrekt. Die Hamony API ist weiterhin erreichbar (bspw. über den Aufruf der entsprechenden URL). Ein Neustart von homeeup hilft nicht um die Geräte wieder erreichbar zu machen. Wenn ich allerdings in homee ein neues WLan-Gerät hinzufüge, das HomeMatic Gateway auswähle, die entsprechende IP des Raspberrys eintippe und mich damit verbinde sind alle Geräte wieder verfügbar. Ich muss dazu auch kein neues Gerät einbinden, sondern kann den Vorgang danach abbrechen.
Mir scheint es als verliert homme also die Verbindung zum Gateway. Ist das ein bekanntes Problem?
Das passiert immer, wenn homee neustartet.
Und das muss nicht unbedingt ein gewollter Neustart sein.
Der homee startet auch schon mal ganz von alleine neu - Im Tagebuch kontrollieren.
Z.B. wenn er nicht genug Strom bekommt. Leidvoll selbst erfahren.
Ja, das Problem ist bekannt und passiert, wie @memooo sagte, immer, wenn homee neu gestartet wurde. Hat jemand eine echte CCU2 und kann Auskunft geben, ob sich homee damit gleich verhält?
Ich habe eine echte. Kann da das Verhalten so nicht bestätigen - läuft ohne Probleme.
Ok, das ergibt Sinn, insbesondere da der letzte Ausfall nach einspielen des aktuellen homee-Updates auftrat.
Wobei ich, wie von @sublevel7 erklärt, nicht jeden Ausfall auf einen von mir ausgelösten Neustart zurückführen konnte.
Kennt Ihr einen effizienteren Weg die Geräte zu reaktivieren, als das Gateway neu abzufragen?
Hallo zusammen
Ich schalte mit HDMI-CEC den TV ein und aus. Das klappt soweit auch.
Für das StatusCmd habe ich mich an _kevdi’s Lösung für „vgencmd display_power“ angelehnt, scheitere aber noch und hoffe auf Eure Hilfe:
„onCmd“: „echo ‚on 0‘ | cec-client -s -d 1“,
„offCmd“: „echo ‚standby 0‘ | cec-client -s -d 1“,
„statusCmd“: „echo ‚pow 0‘ | cec-client -s -d 1 | sed ‚s/power status: on/0;s/power status: standby/1‘“,
„checkInterval“: 5000
Die Fehlermeldung lautet:
statusCmd failed with error Error: Command failed: echo ‚pow 0‘ | cec-client -s -d 1 | sed 's/power status:on/0;s/power status:standby/1’<
sed: -e Ausdruck #1, Zeichen 24: Unbekannte Option für »s«
Bei der Abfrage über die Kommandozeile…
echo ‚pow 0‘ | cec-client -s -d 1
… bekomme ich als Antwort:
power Status: on
oder
power Status: standby
Hat jemand eine Idee?
Ich konnte den Fehler mittlerweile selber finden. Ich hatte zwei Slashes vergessen:
Korrekt ist also:
“statusCmd”: “echo ‘pow 0’ | cec-client -s -d 1 | sed ‘s/power status: on/0/;s/power status: standby/1/’”,
Vielleicht könnt ihr mir aber noch helfen wie ich es hinbekomme, dass der Status nicht immer wieder auf aus sprinkt im Homee…