Ich hab morgen wieder ein "Meeting" mit unserem Kontakt von ABB/BJ - er kennt unser Dilemma zwischenzeitlich und will morgen nochmal alle Punkte mitnehmen, damit es vielleicht nicht nur im Call-/Support-Center bleibt, sondern auch an die richtigen Stellen kommt.
Wenn ich was Neues erfahre, melde ich mich! 🙂
free@home
SAP/S.13 v3.2.2 | 14x Bus | 1x Wireless | hue | Home Assistant | Alexa
Da ich selbst erst seit fast 2 Jahren ein Raspberry besitze und mit programmieren noch ein Rookie bin könnte ich dir vorschlagen, Node-Red auf dem Raspberry zu installieren. Da kann ich gerne weiterhelfen, eigene Nodeszu schreiben. Die Oberfläche ist absolut anwenderfreundlich und seit ich es geschafft habe eine websocket Verbindung herzustellen, kann man damit eigentlich alles realisieren was man so will. Ich habe mir z.B. unter anderem ein Dashboard erstellt, wo ich Befehle an F@H, TV und Heizung senden kann. Überleg es dir einfach, dann helfe ich gerne in die Richtung weiter.
Gruß Michael
Ich hab morgen wieder ein "Meeting" mit unserem Kontakt von ABB/BJ - er kennt unser Dilemma zwischenzeitlich und will morgen nochmal alle Punkte mitnehmen, damit es vielleicht nicht nur im Call-/Support-Center bleibt, sondern auch an die richtigen Stellen kommt.
Wenn ich was Neues erfahre, melde ich mich! 🙂
Gerne!
Das mit dem Projekt "externes Dashboard" und auch node-red klingt gut. Ich habe mich bisher mit sowas zurückgehalten, weil unser f@h nie wirklich so funktioniert hat wie es soll ... wenn sich das ändert, wär ich gerne mit dabei!
Dafür gibt's solche Foren wie hier letztlich ja!
free@home
SAP/S.13 v3.2.2 | 14x Bus | 1x Wireless | hue | Home Assistant | Alexa
Super, ich glaube, BJ bekommt schon ein wenig mit, dass ihre Schnittstelle enorm viel Potenzial hat und das wiederum free@home interessanter für neue Kunden macht...
...ein paar Kleinigkeiten hier und da würden (mir) schon viel helfen. Vor allem, dass free@home autonomer agiert, also Aktionen ohne extenrner Programmierung schafft (vom einfachen Verzicht auf irgendwelche Rüchmeldungen bis zum selbständigen Erstellen dynamischer REST-API Calls für Herd, Saugroboter & Co).
Sobald man (vieles selbst) programmieren muss, ist es nicht mehr weit, dass man auf free@home verzichten kann. Ich habe mir beispielsweise in den letzten drei Wochen ein Tool geschrieben, welches bei mir die gesamte Lichtsteuerung übernehmen kann - und zwar schneller, flexibler und zuverlässiger als mit free@home. Das hat mich doch ziemlich überrascht und bedeutet, dass ich mein Haus nun zweigleisig steuere - ist auch nicht im Sinne des Erfinders...
Das ist es ja!
Ich finde ebenso, dass f@h enormes Potenzial hat und habe daher letztlich beim Modernisieren auf das seinerzeit noch recht unbekannte System gesetzt. Vor allem eben weil es auf KNX basiert (auch wenn nicht kompatibel), Bus & Funk kombiniert und dann sogar noch "offene" Schnittstellen versprach. Ich glaube ABB/BJ hat sich da Einiges verspielt, weil sich einfach nichts oder nur viel zu wenig getan und entwickelt hat ...
Man vergleiche die Fortschritte z.B. bei Homematic IP, Loxone, hager KNX easy, ...
Da ging es im gleichen Zeitraum richtig voran. Viele neue Geräte, stetig bessere Funktionen und und und.
free@home
SAP/S.13 v3.2.2 | 14x Bus | 1x Wireless | hue | Home Assistant | Alexa
Wenn Du möchtest kann ich Dir das Programm compiliert für Raspi zukommen lassen. Das ist dann nur eine Datei die man direkt ausführen kann.
Wirklich sehr verlockend! Kann ich das dann dauerhaft im Hintergrund laufen lassen, so dass es mir die ganze Zeit das Netzwerk beobachtet? Würde es mit jedem virtuellen Switch automatisch funktionieren?
Ich werde mir das auf jeden Fall anschauen! Habe mich mit Node Red bisher noch nicht so wirklich befasst. Danke auf jeden Fall für dein Angebot. Ich komme darauf zurück, sobald ich mir einen Überblick verschafft habe
Hi! Habe Dir als PM einen Dropbox Link auf die Tools compiliert für den raspi geschickt. Kannst Du ja mal ausprobieren. Würde mich interessieren, ob sie so funktionieren.
Ja, dem fahvswitch Programm gibt man lediglich die F@H ID des vorher angelegten Virtual Switches mit und dann läuft es endlos, bis man es mit CTRL-C oder kill abbricht.
Hallo guckykv, das klingt sehr gut und auch so als würde es mein Problem mit dem "nicht schaltenden VS" lösen können. Läuft das dann in openhab oder einfach auf dem raspberry? Ich hatte versucht sowas direkt in openhab mit einer Regel oder Script umzusetzen um es für den User einfach zu halten. Hast du dazu eine Idee bzw. nutzt du openhab?
Kurze Rückfrage zu dem Programm. Die Gefahr besteht doch, dass z.B. das externe Gerät das Signal nicht sauber verarbeitet und das Programm dann sagt, der Schalter ist an, obwohl das externe System nicht auf ON gewechselt hat? Oder gibt es darauf noch eine Prüfung?
Danke!
Danke dir für die ausführliche Erklärung. Mein Problem ist jedoch dass der Schalter nie den Status wechselt, wenn ich diesen drücke. Der Ausgangspunkt ist ja immer der virtuelle Schalter und nicht irgend ein Befehl der über den Swagger kommt. Wenn ich dich richtig verstehe meinst du aber ich müsste vom externen System (in meinem Fall openhab) die Rückmeldung an den Schalter senden damit dieser umschaltet?
Der Schalter wechselt beim eigentlichen Drücken schon den Status (der Wert ändert sich). Das Symbol ändert sich jedoch erst wenn auch der odp0000 des Schalters verändert wird. Dieser wird eben nicht durchs f@h verändert sondern durch ein externes Programm, in meinem Fall Node Red.
Kann es gerne per Teamviewer zeigen wenn Interesse besteht. Falls ja, einfach eine PN an mich ?
Gruß Michael
Ja, das fahvswitch Programm läuft "endlos" weiter. Bis man es bewusst abbricht.
Es lauscht derweilen immer auf den Websocket Nachrichtenstrom und spiegelt für den Switch den Input auf den Output. Damit macht das Programm selbst natürlich nichts. Für den f@h ist es halt einfach ein Actor, den er betätigen kann und der dann einen Zustand (an oder aus) hat.
Spannender wird es natürlich, wenn das eigene Programm auch wirklich etwas damit macht. Also eigene Dinge im Hintergrund anstößt.
Ich möchte z.B. (sobald ich mal wieder etwas Zeit habe) ein Programm schreiben, welches ein virtuelles Device erzeugt, das die Brücke zu einem Denon HEOS System schlägt. So dass man per Schalter oder Szene auch das Denon System (ähnlich dem Sonos) steuern kann. (Wobei ich mir noch nicht sicher bin, in wie weit f@h tatsächlich etwas Sonos äquivalentes als virtuelles Device unterstützt.)
Hallo guckykv, das klingt sehr gut und auch so als würde es mein Problem mit dem "nicht schaltenden VS" lösen können. Läuft das dann in openhab oder einfach auf dem raspberry? Ich hatte versucht sowas direkt in openhab mit einer Regel oder Script umzusetzen um es für den User einfach zu halten. Hast du dazu eine Idee bzw. nutzt du openhab?
Das ist ein eigenständiges Programm, das man direkt auf den raspberry startet. Das hat sonst keine Abhängigkeiten. Das verbindet sich mit dem SysAP und das war es dann auch. Danach sollte der virtuelle Switch im Sinne des SysAP funktionieren. (Er tut natürlich sonst noch nicht wirklich etwas)
Kurze Rückfrage zu dem Programm. Die Gefahr besteht doch, dass z.B. das externe Gerät das Signal nicht sauber verarbeitet und das Programm dann sagt, der Schalter ist an, obwohl das externe System nicht auf ON gewechselt hat? Oder gibt es darauf noch eine Prüfung?
Also mein Programm verarbeitet das Signal ja nicht wirklich. Es spiegelt den Input Wunsch des SysAP als Output zurück an den SysAP.
Aber ja, wenn das Programm nicht läuft, sprich niemand sich um das virtuelle Device "kümmert", dann merkt man es daran, dass die virtuelle Lampe im SysAP einfach nicht an geht.
Wenn das Programm mal wirklich was tun soll (Receiver anschalten / Garagentor öffnen / ...), dann darf das Programm das halt erst dann erfolgreich an den SysAP zurück melden, wenn die Aktion bei dem externen Gerät auch tatsächlich geklappt hat.