Die Meldung hatte ich gestern auch nachdem ich den HA-Core geupdatet habe.
Hast Du eine Sicherung, die Du zurückspielen kannst?
Falls Du auch das Update gemacht hast…
Reroll hat funktioniert! Danke!
Ich habe jetzt nochmal alles ohne USB-300 neu installiert und sehe auch wieder die oben gezeigten Schalter und Statusanzeigen.
Allerdings bleibt das Problem das gleiche: Weder der Druck auf die “Lichtschalter” in HA, noch die Rollladenbuttons sorgen für irgendeine Aktion.
@philipp14 Hast Du eine Idee, an was das liegen könnte? Danke!
Hallo zusammen, die Fehlermeldung hängt mit dem neuem HA Release 2024.9.1 zusammen und einer Library (Requirement) die zusätzlich zur Integration installiert werden.
Ich konnte leider noch nicht herausfinden woran es liegt das sich weder an der Eltako Integration noch in HA an der Stelle etwas geändert hat.
Wenn ihr eure schon beschrieben die Versionsnummer weg lasst, dann wir eine alter Version installiert, die noch nicht vollständig ist und deswegen funktioniert z.B. das Senden über USB300 nicht.
Aktueller work-around ist das Backup von 2024.8.* einzuspielen und auf ein fix zu warten.
Sorry, wird noch ein bisschen dauern da ich im Urlaub bin und es auch nicht offensichtlich ist woran es liegt.
Vielleicht kann sich auch jemand den Requirements Manager in HA anschauen und hast eine Idee. Meine Tests waren bisher alle positiv.
Hallo philipp14,
das erklärt Einiges!!!
Ich habe die letzten Tage hin und her probiert, IDs manuell ausgetaucht, via PCT14 und eo_man neu konfiguriert, etc. Es funktionierte einfach nicht!
Kein Wunder, wenn das Senden des USB300 mit der 2024.9 nicht fuktioniert.
Ich habe mir nämlich auch mit dem Entfernen von “delete==0.2.6” geholfen, da ich keine adäquate Sicherung der 8er Version zum rücksichern habe. Na, dann sind immerhin meine Selbstzweifel etwas relativiert.
Ich beschäftige mich zwar noch nicht intensiv mit HA, aber ich kann es ja mal versuchen. Wo bzw. wie lässt sich der Requirements Manager aufrufen?
Viele Grüße & einen schönen Urlaub!
Ich kenne mich leider auch nicht so gut aus. Der RM checkt die abhängigen Libraries und sorgt dafür dass sie kompatibel sind und das System nicht vermüllt.
In der Datei wird auch der Fehler geworfen.
Ich habe es versucht nachzuvollziehen, allerdings hat bei mir alles soweit funktioniert und es wurden auch keine Änderungen gemacht. An einigen Stellen wird auf Python libs zu gegriffen vielleicht sind auch dort Änderungen drin.
Es gibt ein neues Release das jetzt mit HA 2024.9 kompatibel ist und die Änderungen, die ich zwischendurch gemacht hatte sind auch mit drin.
Mit der neuen Version lässt sich “Eltako” wieder mit dem aktuellsten Core-Update integrieren und starten.
Leider schaffe ich es trotzdem nicht über die Startlinie. Allerdings denke ich, dass es etwas mit den IDs zu tun hat. Im eo_man wird mir vom USB300 eine andere MAC angezeigt als auf dem Dongle steht. Verbleibt der Dongle im Notebook mit dem ich auch die Daten via PCT14 ins FAM14 schreibe, kann ich via “Send Message” schalten.
Nehme ich den Dongle ab und schließe ihn wieder an den Pi auf dem HA läuft, geht gar nichts. Ich habe in der .yaml beide MAC-Varianten des Dongles als Sender-ID ausprobiert. Auch die IDs, die aus der Base-ID des Gateways (FAM14) abgeleitet werden, habe ich etwas höher gezählt angesetzt, da ich noch FHEM in Betrieb und ich ausschließen wollte, dass es zu Kollisionen kommt.
Vielleicht hängt es bereits bei der Integration. Sieht folgende Abfrage bei euch auch so aus? Was wählt ihr aus?
Hallo @newBuddy,
kannst du nicht die Konfiguration vor dem Update verwenden?
Die Anzeige für die Auswahl ist wichtig. Hier wählst du das Mapping zwischen USB Port und Gateway Konfiguration aus.
Bei dir steht allerdings FAM14 anstatt USB 300 dran. Kann es sein dass die Konfiguration für USB 300 fehlt?
Hi philipp14,
danke für Dein Feedback.
Die Konfiguration mit dem USB300 als (einziger) Gateway brachte bisher immer nur ein Gerät oder Fehler bei der Integration von “Eltako”. Daher bin ich davon ausgegangen, dass ich den FAM14 als (Empfänger-) Gateway und den USB300 quasi als Sender angeben muss.
…
Desweiteren eine Verständnisfrage:
HA läuft auf einem Pi an dem der USB300 angeschlossen ist.
Welches Gateway muss in der config von HA aufgeführt werden?
FAM14 oder der USB300?
Ich probiere es nochmal mit dem USB300 als Gateway und berichte.
Wenn du am R-PI nur den USB300 hast, dann reicht dessen Konfiguration aus.
In der Konfiguration unterhalb der jeweiligen GWs gibst du die Geräte, an die HA kennen soll und über das GW läuft dann auch die Kommunikation, auch wenn die anderen GWs die Signale empfangen.
Wenn du z.B. nur ein Gerät bei USB300 konfiguriert hast und nur diesen in HA ausgewählt hast, dann siehst du auch nur das eine Gerät.
Du kannst mir auch gerne mal die Konfiguration als private Nachricht schicken.
Mit Hilfe von philipp14 läuft nun auch meine Eltako-Integration. Grund war eine bzw. die parallel laufende EnOcean-Integration. Beide haben den USB-Dongle für sich beansprucht, was letztendlich zu Fehlern und (bei mir) zur Deaktivierung der Schnittstelle führte.
Deaktivieren von EnOcean hat nichts gebracht. Also, habe ich eine Sicherung gemacht, die Integration und entsprechenden Code in .yaml-Dateien gelöscht. Nach einem Neustart von HA lief die Eltako-Integration tadellos.
Eventuell muss die Integration von Eltako nach dem Neustart wiederholt werden.
Viele Grüße & vor allem besten Dank!!!
Guten Morgen Ihr Lieben.
bin gestern endlich wieder dazu gekommen weiter zu machen
zuerst aber Danke für die tolle Arbeit und Unterstützung hier im Forum und überhaupt!
Den eo manager habe ich auch zum Laufen bekommen, hier war das größte Problem die automatische Sicherung von Onedrive die Probleme gemacht hat.
Bin wie folgt vorgegangen
- FAM14 mit dem eo manager ausgelesen
- USB300 angeschlossen
- HA Configuration erstellen lassen und so wie erstellt eingefügt
- im eo manager auf die Schaltfläche “Write HA senders to device” → FAM 14 schreiben lassen. Anschließend habe ich mit der PCT Software von Eltako den FAM14 ausgelesen, hier waren allerdings keine neuen Einträge vorhanden.
- HA Configuration in die configuration.yaml eingefügt
- Eltako Integration gestartet.
Und es wurden 79 Geräte erkannt Es wird jetzt nur der Status bspw. vom Licht erkennt, also ob es an oder aus ist. Senden kann ich leider nichts.
Entsprechend lang wurden auch die Zeilen, aber damit kann man sehr gut leben.
Immerhin bin ich schon einen Schritt näher. Ich nehme an, es fehlt noch eine elementare Einstellung irgendwo. Vom Gefühl, dass im FAM14 der USB300 noch eingetragen werden müsste oder was Ähnliches.
Die HA Core Version ist die 2024.9.3
Vorher der Installation war noch die Enocean Integration aufgespielt, die hatte ich entfernt.
Entweder dadurch oder durch den eo manager hat sich auch die ID vom USB300 geändert, wurde aber vom eo manager erkannt (nehme ich an).
Ich sag jetzt schon einmal Danke für Eure Hilfe.
Ja genau.
Die Adressen von deinem USB300 müssen noch in die Busgeräte eingelernt werden.
Mir ist auch aufgefallen, dass die Doku unvollständig war und habe sie kurz ergänzt.
Sorry, dass ich so kurz angebunden bin. Bei mir ist gerade viel los. Frage gerne noch einmal nach, wenn du nicht weiterkommst.
Vorweg, es klappt jetzt
Also noch einmal vielen Dank für die coole Integration und das eo-Tool!
Dank der Überarbeitung der Anleitung hat es jetzt auch bei mir geklappt. War nur wichtig, sich genau an den Bildern zu orientieren und die Reihenfolge einzuhalten.
Hat zuerst das Problem, dass der USB300 nicht zum Beschreiben angezeigt wurde. Jedoch, wenn man etwas rum versucht und den USB300 anzeigt und dann zurück zum FAM14 wechselt, bleibt es dann rechts im Bereich “Program Ha senders into device…” also wie auf dem Bild eben
Beim ersten Ausleseversuch kamen drei Fehlermeldungen bei den sender-id´s, nach mehrmaligen versuchen, hat es die jetzt auch beschrieben. Heißt, alle Rollläden und Lichter lassen sich steuern.
Einziger, winziger Schönheitsfehler, mit dem ich aber sehr gut leben kann, ist noch, dass bei Lichtern, die über mehrere Schalter gesteuert werden, es zu Überschneidungen kommt. Müsste ggf. die Rückmeldung abwarten. Wobei, das hat bei den Rollläden zu falschen Anzeigen geführt.
Da für mich die Rollläden wichtiger als Lichter sind, kein Thema
Noch einmal Danke für die Unterstützung hier im Forum, ohne die würde ich noch bis 2030 oder länger daran sitzen.
Das Witzige daran ist, hab wegen der Rollladen und Lichtern mit Smart Home und HA überhaupt erst angefangen und jetzt ist es das letzte Thema, welches fertig geworden ist. Jetzt kommen nur noch Spielerein.
Hallo @mar-kus,
schön zu hören das es klappt.
Ich habe aktuell noch keine Rolladen verbaut und deswegen kann ich es nicht testen.
Ich gehe davon aus, dass wir das Thema auch noch in den Griff bekommen und es mit einem Update erledigt ist. Wird allerdings noch ein bisschen dauern.
Hallo zusammen,
ich bin vor ein paar Tagen in die Home Assist Integration für meine Enocean Eltako Komponenten eingestiegen und habe mit großem Interesse diese Unterhaltung gelesen. Vorab schonmal vielen Dank an @philipp14 für deine tolle Integration!
Ich betreibe mein Home Assist auf einem NUC innerhalb einer VirtualBox mit angeschlossenem USB300, der auch erkannt wird. Lichter und Rollläden werden über FAM 14, FSR14-2x und FSB14 angesteuert. Diese will ich jetzt über Home Assist ansprechen.
Nach anfänglichen Schwierigkeiten habe ich die Integration zum laufen gebracht und kann meine Aktuatoren ansteuern
Zwei Fragen / Probleme habe ich allerdings noch.
- Wenn ich einen virtuellen Schalter in HO auslöse, sehe ich ihn in der PTC14 Software nicht, wenn ich dort nach gedrückten Schaltern lausche. Die normalen Wandschalter werden angezeigt. Es funktioniert zwar letztendlich und die Lichter und Rollläden reagieren, trotzdem würde mich der Grund dafür interessieren…
- Ich habe in der configuration.yaml auch meine binären Sensoren konfiguriert. Ich verwende hier PTM215. Allerdings werden diese im Logviewer nicht angezeigt. Ich habe noch nicht versucht sie in einer Automatisierung zu verwenden, das will ich zeitnah versuchen. Trotzdem wäre es natürlich zu debug Zwecken gut wenn ich im Logviewer was sehen würde… Die Virtuellen Schalten werden bei Betätigung angezeigt.
vielleicht hat ja jemand eine Idee zu den beiden Problemen.
Guten Morgen,
ich kann ein update zu meinem Post von gestern geben.
Nachdem ich in der configuration.yaml unter “logger” den Wert von eltako von info auf debug gesetzt hatte, konnte ich das Auslösen der Schalter sehen.
Es bleibt also nur noch meine erste Frage warum ich in PTC 14 nicht die Ausgelösten virtuellen Schalter sehe.
by HarryP: Zusammenführung Doppelpost (bitte “bearbeiten” Funktion nutzen)
Hallo @massarius,
zu 1. hätte ich dir auch nur empfehlen können per debug in die logs zu schauen: home-assistant-eltako/docs/logging at main · grimmpp/home-assistant-eltako · GitHub und du kannst auch den eo_man anschließen. Wenn du den USB300 in HA eingesteckt hast kannst du z.B. per USB auf FAM14 gehen und mit eo_man alles auslesen.
Ich bin aktuell daran die Version 2 von der Integration zu bauen, dann wird es eine Remote/Netzwerk-Verbindung zu eo_man geben damit man alle Gateways einfach in HA eingesteckt lassen kann. (Vorausgesetzt ich bekomme alle Verbundingen stabil aufgebaut. Das ist mit FAM14 leider nicht so einfach möglich.)
Alternativ kannst du auch beide FAM14 und USB300 in HA einstecken und konfigurieren so siehst du in LogViewer was die beiden gegenseitig empfangen und verschicken.
Falls du noch Verbesserungswünsche hast gerne her damit. Jetzt ist ein guter Zeitpunkt.
Zu 2.: Ich glaube in PCT14 ist ein Filter eingebaut, ich kann dir leider auch nur sagen, dass man nicht alles sehen kann.
@philipp14 du hattest recht. Es war ein Filter in PCT14. Ich habe auf “alle Telegramme” umgestellt und kann meine Botschaften jetzt sehen.
Nun zu meiner nächsten Aufgabe: Ich möchte bei Sonnenaufgang / Untergang bestimmte Rollläden automatisch hoch/runter fahren. Zuerst hatte ich naiv einfach eine Gruppe erstellt und diese in einer Automatisierung getriggert. Allerdings fahren nicht alle Rollläden runter. Ich vermute, dass dabei zu viele IDs auf einmal gesendet werden.
Mein zweiter Ansatz sieht nun so aus, dass ich die Aktion “send_message service” verwende. Ich habe eine neue ID erstellt und diese in allen Rollläden, die ich runter fahren will eingelernt. In der Automatisierung sieht das dann so aus:
Die Werte für command und learn_button habe ich aus der Botschaft, die gesendet wird, wenn ich einen einzelnen Rollladen runter oder rauf fahre.
Das funktioniert auch. Trotzdem habe ich noch ein paar Fragen:
- ist das der bevorzugte Weg? Könnte ich in der configuration.yaml auch irgendwie einen virtuellen sender anlegen und diesen in der Automatisierung verwenden?
- Im log sehe ich nach der Aktivierung eine Warning Missing EEP (H5_3F_7F) args: {}) . Habe ich noch etwas vergessen?
- Die “time” ist ja eigentlich individuell für die verschiedenen Rollläden. Ich habe gesehen, dass nach Ablauf der Zeit eine Antwort vom FAM mit dem Status kommt. Gibt es Probleme, wenn ich die Zeit zu kurz angebe?
- keine Ahnung was lean_button 1 bewirkt…
Hallo @massarius,
cool, dass du gleich auf die Funktion gestoßen bist.
Wie viele Rollladen möchtest du denn auf einmal steuern?
zu1.:
Ja, das ist leider ein Problem, wenn man zu schnell viele Telegramme auf einmal auf den Bus schickt. Ich habe dafür schon ziemlich früh ein message delay eingebaut, das man unter der gateway Sektion in der Konfig eintragen kann. Allerdings verlangsamt es dann auch alle Nachrichten.
Unterm Strich kann man sagen, HA ist schneller als das FAM14 bzw. die USB Gateways und dann läuft der interne Speicher über bevor es auf dem Bus ausgegeben werden kann.
Ich habe es mir noch nicht genau angeschaut aber sowie zum Beispiel bei Zigbee können für Gruppen eine Id verwendet werden, die dann gesendet wird. Eigentlich funktioniert, dass dann analog zu dem was du vor hast.
Ich werde es mir aber auf jeden Fall mal anschauen, ob man an der Stelle etwas sinnvolles Erweitern kann. Schreib mir gerne wenn du etwas herausfindest.
- Kannst du die Warning mal schicken?
- In aller Regel sollte es egal sein ob die Zeit zu kurz oder lang ist die Rollladen haben auch normalerweise einen Anschlag/Schalter, damit sich der Motor ausstellt wenn er ganz auf oder zu ist. Es könnte natürlich sein, dass HA irgendwann nicht mehr weiß wo er seht wenn du ihn nicht ganz auf oder zu machst. Ich glaube die Zwischenzustände werden nicht als Nachrichten geschickt. (Habe meine Rolladen leider noch nicht mit HA verbunden und kann es nicht auf die Schnelle testen.)
- lean_button wird auf 0 gesetzt wenn man Einlerntelegramme versenden will. Damit könntest du die ID im Telegramm in einen Aktor einlernen wenn du dessen Drehrad auf LRN stellst. Das wirst du z.B. benötigen wenn du dezentrale Aktoren hast.
Sehr cool, was du mit der Integration machst. Lass mich bitte wissen, wie es läuft damit ich sie weiter verbessern kann.
Was mir bei der Automatisierung der Rollläden geholfen hat, war ein kleiner Versatz (0,5 Sekunden) bei der Automatisierung zwischen jedem Rollladen.
Damit konnte ich das Problem lösen.
So gehen im EG die Rollläden dann hintereinander hoch bzw. runter. Dies könnte man entsprechend auch auf die Sonnenstände abändern.
Lese ebenfalls weiter mit, da dies für den Sommer ebenfalls interessant ist