Lokale API mit REST und Websocket API

Hallo Georg,

ich habe das mal mitgelesen und es so verstanden, dass mein Szenario damit funktionieren müsste, mir fehlt nur die Rückmeldung von openhab, dass der Schalter auf ON soll.

Szenario: Virtueller Aktor in f@h wir aktiviert, in openhab habe ich ein Script erstellt, wenn der virtuelle Aktor auf ON geht, soll die Lüftung angeschaltet werden.

Innerhalb von openhab funktioniert das auch wunderbar, jedoch kommt der ON Befehl von f@h nicht in openhab an, da der Schalter auch immer wieder auf OFF springt. Heißt das, dass der Befehl sehr wohl in openhab ankommt, ich aber in dem Moment wo er ankommt rückmelden müsste, dass es angekommen ist und der f@h Schalter jetzt auf ON stehen soll?

Ich bin nicht der Programmierexperte, aber an sich sollte mein Szenario nicht all zu schwer sein und es klingt nach deiner Beschreibung so, als fehlt mir nur noch die Info dass der Schalter ON ist?

@hubi

Ein kleines Beispiel, wie ich zurzeit einen realen Schaltaktor verwende:

• Aktivierung erfolgt durch das Panel (dafür verwende ich eine Szene, weil es hier unterscheidbare Symbole gibt - sonst hätte ich lauter Steckdosen 🙂
• die ganze Zeit "lauern" drei oder mehr Aktionen auf diesen Aktor, etwa:
  - einige Leuchten werden mit einer bestimmten Helligkeit (zeitabhängig) eingeschalten
  - Jalousien werden je nach Status leicht geöffnet
  - der Aktor wird nach 3 Sekunden wieder ausgeschalten

Das ganze ist ziemlich praktisch zu "programmieren" (abgesehen davon, dass die Jalousiepositionen bei den Aktionen immer um einen Tick falsch gelernt werden - hier wäre eine manuelle Eingabe angenehm) und das Ergebnis ist, dass ein einziger Schalter am Panel je nach Situation verschiedene Dinge auslöst:

• Drücke ich am Panel am Morgen auf diese Taste, wird das Licht moderat eingeschalten und die Jalousie (weil geschlossen) wird leicht gekippt (und eine Jalousie wird komplett nach oben gefahren).
• Die gleiche Taste etwas später würde nur das Licht einschalten, da die Jalousien nicht mehr völlig geschlossen sind.
• Noch später würde die Taste das Licht heller aufdrehen.

@hubi

Es würde genauso gehen wie du dir das vorstellst. Ich schreibe mal eben ein bisschen was zusammen um es verständlich zu machen... 

Also du erstellst einen virtuellen Schalter und schaust in der F@h Oberfläche nach, welche Seriennummer dieser Schalter erhalten hat.

 Diese Nummer gibst du dann in der /swagger Oberfläche bei "​/api​/rest​/device​/{sysap}​/{device}

Wenn ich das richtig verstanden habe ist das genau das, was du willst oder? 

Gruß Michael 

Update:

Ich habe den Mechanismus aus meiner obigen Beschreibung in ein kleines Go Programm gepackt.

Siehe: fahvswitch (basierend auf guckykv/freeathome-go-fahapi)

$ DEVICEID=$(fahcli -d virtual --create abcVAct 7200 "Virtual Test Actuator" SwitchingActuator)
$ fahvswitch --id=$DEVICEID

Das fahvswitch läuft dann in einer Endlosschleife und lauscht auf dem Websocket. Wenn Änderungen kommen, überträgt es diese zurück in den SysAP und protokolliert sie in der Console.

Nach kurzem Test scheint es zu funktionieren. Kann das jemand ausprobieren, ob das das tut was ihr von so einem virtuellen Switch Actuator erwartet?

@babelbernd

Genau das macht mein fahvswitch Programm. Man muss nur die DeviceID mitgeben. Dann wartet es darauf, bis sich idp0000 ändert und schreibt den Wert dann nach odp0000.

Das

$ fahcli virtual --create ... 

benötigt man nur einmal, um das virtuelle Device initial anzulegen.

@hubi

Hi! Ich kenn mich nicht in openhab aus. Deswegen hab ich auch keinen Plan, was openhab im Falle von virtuellen Devices an Aufgaben übernehmen würde.

Ich könnte mir aber vorstellen, dass openhab das Device auch als ganz normales Device verarbeiten möchte. Sprich wenn man "ausserhalb" diese Input->Output Logik implementiert, sieht das Ganze für openhab wieder wie ein ganz normales f@h Device aus.

@guckykv

Ich höre hier Go dafür zum ersten mal und könnte nicht mal sagen was ich damit machen soll 😉 Ich versteh einfach nicht warum es in node-red nicht klappt mit dem websocket. Magst du mir das mit dem Go etwas besser erläutern was es genau ist. Vielleicht sollte wir hier besser per PN weiter machen um das Forum nicht unnötig zu belasten? 

Habe dir eh schon mal geschrieben 🙂

Gruß Michael 

Ich habe es heute (nachdem die SD-Karte meines Raspberry verreckt ist und ich das Raspberry neu aufgesetzt habe) endlich geschafft die websocket-Verbindung in node red herzustellen. Das Problem war, dass der websocket keine Authentifizierung unterstützte. Ich konnte es jetzt lösen indem ich der URL User:Passwort voranstellte wie im Beispiel hier: ws://installer:passwort@192.168.178.38/fhapi/v1/api/ws

vielleicht hilft es ja jemandem weiter 🙂

Hallo zusammen!

Man glaubt es nicht, aber bald 3 Jahre nachdem man versprochen hat, es gäbe eine lokale API für f@h ist sie dann tatsächlich auch mal da. Ich habe die neue v2.6.0 erst jetzt mitbekommen, da mein SysAP die nicht automatisch gezogen hat ...

Da ich aber noch den "alten" SysAP vom Typ 6200 AP-101 habe, befürchte ich dass ich nicht in den Genuss der lokalen API komme?!
In diesem Fall überlege ich tatsächlich, eine Beschwerde an BJ/ABB zu richten. Als wir unser Haus modernisiert haben, war die Zusage einer kommenden lokalen API tatsächlich einer der Hauptkaufgründe für uns. Wir hatten von Anfang an geplant, später eine übergeordnete Visualisierung/Steuerung über alle Systeme im Haus zu legen ...

Oder hat jemand mit dem "alten" SysAP die lokale API am Laufen?

VG
Frank

@cypher2020

Also ich habe die V2 vom SysAP. Was passiert denn bei dir wenn du <IP-Adresse>/swagger im browser eingibst? 

Gruß Michael 

Ich habe der Einfachheit halber nen Screenshot angehangen. Vielleicht ist die Meldung ja bekannt, ich könnte noch nichts direkt finden. Habe aber auch noch nicht allzu lange recherchieren können.

VG, Frank

@cypher2020

Also was ich gelesen habe ist dass es anscheinend wirklich nicht funktioniert. Ich hatte mir vor einiger Zeit schon die API von Henry spanka installiert. Schau doch einfach mal hier: 

ttps://github.com/henry-spanka/freeathome-api

Wäre evtl eine Alternative für dich. 

Gruß Michael 

@puffolino

Der SAP macht nichts selber mit dem virtuellen Switch. Wenn du ihn in der App "anschaltest", dann schickt der SAP das als Event in dem WebSocket Stream. Dort muss jemand, der sich für diesen virtuellen Switch verantwortlich fühlt (ein anderes Programm - dieses simuliert eben ein "echtes Gerät") darauf lauschen und entscheiden was er mit diesem anschalt Wunsch macht. Normalerweise wird er dem Wunsch nachkommen und per REST API dem SAP zurückmelden "ja, ist an". Dann zeigt der SAP den Schalter auch als an an.

Ich hab zum Testen mal ein ganz einfaches Programm geschrieben, dass das macht:

guckykv/freeathome-go-tools - fahvswitch 

Eigentliche Logik siehe fahvswitch/main.go#L62

if deviceId == *deviceIdParam {

prüft, ob die Websocket Message sich um das virtuelle Device dreht

 if channelId == "ch0000" {

Geht es um den ersten (und einzigen) Channel des virtuellen Actuators.

 if datapointId == "idp0000" {

Und dort um den Input Datpoint der sich um das an/aus kümmert

 setValue(deviceId, channelId, "odp0000", value)

Dann setze per REST den korrespondierenden Output Datapoint auf den selben Wert, wie er über den Input gerade rein kam.

@guckykv

solch ein kleines Programm ist mega. Eigentlich würde das doch all die "Probleme" mit der lokalen API und den zugehörigen virtuellen Switches lösen, wenn man das im Hintergrund (z.B. auf einem Raspi) mitlaufen lassen könnte, es auf Schaltungen virtueller Geräte "lauscht" und dann den Status zurückmeldet, oder?

Da ich leider nur anwenden, aber nicht programmieren kann,  jetzt meine Frage: Wäre es (Dir oder jemand anderem hier) möglich, solch ein kleines Programm für den Raspi umzusetzen?