• CODetector and FIRE Detector as virtual devices are undocumented

    The above mentioned devices are havig undocumented pairing IDs. This shall be added to the documentation

    Status: Proposed | Reported by Hidden Tue, 31 Jan 2023 06:00:40 GMT
  • Virtual device type is needed for keep-alive signal of a virtual device

    The virtual device keep-alive signal is not working with a simplified json object e.g {"properties": {"ttl": "60"}} as seen in the example as well but the device type must be specified otherwise a negative response is received. In the case keep-alive signal it is unneccessary to send the device type and in many use cases maybe the device type is not known or not interessting for keeping the device alive The device type shall be optional as stated in the example.

    Status: Proposed | Reported by Hidden Tue, 31 Jan 2023 05:59:17 GMT
  • Websocket connection is cyclically closed with code 1006 with SysAP 3.x.x

    As developer of a Java plugin for free@home using the websocket connection to get immediate status updates. The websocket connection ws stable with the SysAP2.6.3. After the update websocket connetion is closed after 3-5 Minutes of opening of the connection with the error code 1006. Which cnfiguration shall be set that the connection is not closed with this error code.

    Status: Proposed | Reported by Hidden Mon, 23 Jan 2023 22:29:19 GMT
  • free@home flex devices FID list

    Hello, the new free@home flex components get new Function IDs thats not listed, so i need a Updated list to work with it Regards

    Status: Proposed | Reported by Hidden Mon, 25 Apr 2022 12:40:31 GMT
  • Scene trigger information missing for Virtual Device triggers

    Statement: When creating a virtual device using the local API, i'm unable to control the device trough scenes from the SYSAP. Situation: - The virtual device is created using the Local API (/fhapi/v1/api/rest/virtualdevice) with parameters: type=SwitchingActuator, TTL=180 - The device is able to recieve ON/OFF requests to ch0000/idp0000. Both using physical sensors as from the SYSAP webinterface. - The virtual device is coded to send replies by sending ch0000/odp0000 for ON/OFF actor status changes. - The device is working as expected in LightGroups. Problem: Scenes get triggered by a Scene request (AL_SCENE_CONTROL) to idp0003 on channel ch0000. However the content to the scene as documented in the API documentation, chapter ‘Scene support for virtual devices’ scenesTriggered is empty. Example recieved Json: 2021-11-25T15:35:10 {"00000000-0000-0000-0000-000000000000": {"datapoints": {"60005CD9523A/ch0000/idp0003": "9"},"devices": {},"devicesAdded": [],"devicesRemoved": [],"scenesTriggered": {}}} Attached is the transcript for tests. I can provide full implementation code (C#, works both in Windows/Visual Studio and Linux/Mono 6.12)

    Status: Proposed | Reported by Hidden Thu, 25 Nov 2021 14:52:40 GMT
  • Issue between virtual Actor and real Sensor / switch

    wie eben telefonisch besprochen hier der Fehlerbericht zur Weiterleitung an die Programmierer der API/Virtuellen Devices und dem potentiellen Bug in der Zusammenarbeit virtueller Aktor mit Wippen / Sensoren und der Free@Home UI. Zusammenfassung: Wippe und WebUI können anscheinend einen virtuellen Schaltaktor nicht auslösen - schreiben diese ggf auf das falsche Datenelement? Der virtuelle Aktor ist via API durch 1/0 -> ch0000/odp0000 korrekt bedienbar. Schreiben ggf UI und Wippe für virtuelle Aktoren nicht nach ch0000/odp0000, sodass sie diese nicht bedienen können? Ich bin per Email erreichbar . Danke. Die Details: Ausgangslage: Es wurde ein virtueller Schaltaktor via API erzeugt, im Raum platziert und mit einer rechten Wippe (Sensor) eines 2.1 wireless Jalousieaktors verbunden. Der virtuelle Aktor ist im Hintergrund mit OpenHAB3 verbunden, um dort ein Gerät anzuschalten. Dies tut aber nichts zur Sache des hier beschriebenen Problems. Was funktioniert: Der virtuelle Aktor ist problemlos via Swagger/API schaltbar (1 -> ch0000/odp0000) - dann zeigt die UI korrekt das "Licht an" am virtuellen Aktor, und die Wippe zeigt Statuslicht "An" (und OpenHAB schaltet die Lampe ein). Ebenso ist er ausschaltbar via API (0 -> ch0000/odp0000) - UI zeigt "Lampe Aus", Wippe Statuslicht "aus" (und OpenHAB schaltet die Lampe aus). So sieht das in API aus: "An" und so im Free@Home Monitor "An": API "Aus": Monitor Verlauf "Aus": Problem / was nicht geht: Der Benutzer soll den virtuellen Aktor natürlich nicht via API bedienen, sondern dies via WebUI und Wippe (siehe unten) machen, dies geht leider nicht. Drücken des Aktors in der WebUI "An": Monitor: Drücken Schalterwippe "An" (rechts): Monitor:

    Status: Proposed | Reported by Hidden Wed, 28 Apr 2021 15:32:05 GMT
  • LocalAPI results in "500 internal server error" after update of Sysap 2 to firmware 2.6.2

    LocalAPI results in "500 internal server error" after update of Sysap 2 from 2.6.1 to firmware 2.6.2 Tried disable / re-enable Local API. Tried different users. Tried /Swagger, curl and access through (previously on 2.6.1 working) NodeRed Flows, same error, all result in a 30sec - 60 sec delay then "500 Internal Server Error". Restarting Sysap , power off and on SysAp all did not help. Disabled nodeRed to ensure this is not a rate limiting / authentication issue same effect when trying just on /Swagger after a wait and/or a restart of the Sysap. Please advise as the Local API integration here is critical for the house.

    Status: Proposed | Reported by Hidden Wed, 28 Apr 2021 15:18:35 GMT
  • LocalAPI results in "500 internal server error" after update of Sysap 2 to firmware 2.6.2

    Update from 2.6.1 to 2.6.2 Local API can not be accessed anymore, all Local API Requests result in 500 Internal Server Error Restarting SysAP, disable and re-enable of Local API, using different users all does not help Same issue through /Swagger, through commandline curl, through previously working NodeRed flows, all result in the same error.

    Status: Proposed | Reported by Hidden Wed, 28 Apr 2021 15:15:15 GMT
  • After some hours of idle the "Error 429 Too Many Requests" is reported from SysAP to HTTP requests

    For my environment I developed in JAVA a connection plugin for the SysAP "Version 2.6.1" with the local API In my tests I get the Error 429 Too Many Request after some hours of idle to the new HTTP request. Practially on Parallel to the HTTP REST API communication a websocket is opened to get the status updates for the connected devices. I am using a jetty HttpClient and for the communication I set the SetMacConnectionPerDestination to 1. The Websocket connection is still alive even if the HttpClient reporting the above error. Is there any time limitation of the HTTP requests? Is any time limitation of the opened Websocket connection with parallel Http REST API commands?

    Status: Proposed | Reported by Hidden Thu, 22 Apr 2021 18:10:48 GMT
  • Refreshing a virtual device always result in a 400 Bad Request

    Hi! I've written some tools around the local free@home API. See and With that I also can register virtual devices - which works fine. But if I try to refresh them, I always get a "400 Bad Request". And I get the error also when I try the curl from your documentation. curl -v -X PUT --user a33xxxxxxa8:xxxx -d '{"properties": {"ttl": "60"}}' * Trying * TCP_NODELAY set * Connected to ( port 80 (#0) * Server auth using Basic with user 'a33xxxxxxxa8' > PUT /fhapi/v1/api/rest/virtualdevice/00000000-0000-0000-0000-000000000000/abc7777 HTTP/1.1 > Host: > Authorization: Basic xxxxxx > User-Agent: curl/7.64.1 > Accept: */* > Content-Length: 29 > Content-Type: application/x-www-form-urlencoded > * upload completely sent off: 29 out of 29 bytes < HTTP/1.1 400 Bad Request < Server: < Date: Sun, 31 Jan 2021 15:34:12 GMT < Transfer-Encoding: chunked < Connection: keep-alive < * Connection #0 to host left intact * Closing connection 0 Using SysAPv2 with system 2.6.0. So, whats going wrong? Regards!

    Status: Proposed | Reported by Hidden Wed, 03 Feb 2021 11:10:01 GMT

You're not signed in. Please sign-in to report an issue or post a comment.