• 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
  • Channel arrangement for different modules.

    Is there any document available from where channel assignment or what each channel represent for different module types can be referred to? eg. for Switch Actuator: (ch0000 = Left rocker, ch0001 = Top, left push button, ch0002 = Bottom, left push button ..... ch0006 = Switch Actuator-1, ch0007 = Switch Actuator-2, etc..). Regards,

    Status: Proposed | Reported by Hidden Wed, 06 Jan 2021 02:41:06 GMT
  • How to enable 'Local API' in System Access Point Model 'SAP-S-2'

    We are presently working on System Access Point Model SAP-S-2 to develop driver plug-in for RTI processor. Read about 'free@home Local API' to control & monitor devices on LAN. Updated the firmware to latest version 2.6.0, however there is no option in 'SAP Settings' to enable 'Local API' as mentioned in API documentation. Are we making any mistake in understanting the documentation or the System Settings? Please guide. Regards, Anil K Chikkam.

    Status: Proposed | Reported by Hidden Mon, 23 Nov 2020 02:35:01 GMT
  • oauth renew and multiple cliente

    I can't have 2 instances of an application connected using oauth and the same user. Steps to reproduce: 1. Log your first application instance ( the application will get access_token1 and renew_token1) 2. Log your second application instance (the application will get access_token2 and renew_token2) 3. wait 3600 seconds, access_token1 will expire and when the first instance try to renew it using renew_token1, an invalid_grant message will be removed, the second instance will be able to renew using renew_token2.

    Status: Proposed | Reported by Hidden Thu, 15 Oct 2020 13:37:49 GMT
  • Scene inputs / outputs swapped?

    I noticed that judging by the pairing IDs the inputs and outputs appear to be swapped for all scenes in my configuration JSON. This makes triggering scenes through the API impossible. "ch0000": { "displayName": "Test Scene", "type": "ABB60341", "functionID": "0037", "inputs": { "idp0000": { "value": "1", "pairingID": 256 }, "idp0001": { "value": "0", "pairingID": 272 }, "idp0002": { "value": "0", "pairingID": 288 }, // ... }, "outputs": { "odp0000": { "value": "0", "pairingID": 1 }, "odp0001": { "value": "0", "pairingID": 16 }, "odp0002": { "value": "0", "pairingID": 17 }, // ... } }

    Status: Proposed | Reported by Hidden Sun, 15 Mar 2020 14:28:58 GMT

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