It is hard to say with no log input.
Could you find out ch / idp / odp (either via SysAp webinterface or using Postman software) when the binary sensor is activated/deactivated?
The new f@h firmware 2.6.0 is out. And it brings a local Rest-Api. Thus it is not anymore necessary to use the API via the BJ developer cloud. Perhaps this offers new possibilities for the further development of this binding.
Can anyone confirm that this firmware works well with the lastest version of this binding?
I try to find out ch / idp / odp.
As i understand, i must register me at the ABB developer portal. Last wendsday i made a request for my individual credentials and developer role to access the APIs, but i have no answer till now. If i can go on, i will answer you.
Did anybody already tried this binding on the openhab3 M2 release? Will it work or are the plans to adopt and port it?
I really like the proposal to make use of the official local API instead of the XMPP interface.
@kjoglums are there any plans to support this?
@martin-h yes for me the binding still works with f@h FW 2.6.0
Well, not sure what the impact/difference of the changes will be as the current version of the binding already uses local connection, i.e. no cloud interaction/internet requirement (local XMPP over websocket).
Also, BJ developers have said (unless change in mind) that the 2.6.0 version will only be supported by Sysap 2.0, not Sysap 1.0 (I myself have the 1.0 version). So others might find interest for further development.
The firmware 2.6.0 is also available for Sysap 1.0:
Yes, cannot find anything for Sysap 1.
Still, uncertain what the changes actually will cause. Will the XMPP over websocket (local), as already used, be eliminated in favor of some other protocol?
the advantage of the websockets (xmpp) is that it pushes changes directly to the client (mobile app/openhab). With the REST API this is not possible. With REST the clients have to query the current state of each device. This is documented ABB Developer Portal
The free@home local API provides a websocket endpoint to enable the API user to get immediately informed about changes to datapoints or the configuration without polling.
Additionally the webservice is also official but not as good documented as the REST API.
As far as I see the REST API is documented with OpenAPI (Swagger). This is a nice tool. For example you can past the swagger file to https://editor.swagger.io/ and generate all java files for a ready to use client. This makes the development of a connection really easy
I totally agree: Getting automatic updates via websocket is much easier than being required to query each device for updates. For large F@H systems, I forsee quite some coding challenges. And, based on the development program, it seems like websockets are sticking (reading outputs).
Seems like inputs via websockets no longer are supported (activation from OH side). Yet, based on statement from @jannodeluxe, the binding still seems to work fine for firmware 2.6.0 version.
The Websocket endpoint is also documented in local API of free@home. I am not sure if ABB Busch Jaeger is planning perhaps to discontinue the xmpp interface as it is and “internal” interface for them?
Dears,
Firmware 2.6.0 works fine with 2.5.8 version of binding.
Hello Stian.
How can I integrate the “Freeathome” addon in OH3?
Well, have a working version of the binding for OH 3.0 (initial version) which could be made available as jar file.
Although, after the M2 release, where /lib folders are excluded, I struggled at first to successfully build the binding for the new environment. After some workarounds, the builds are now successful, but now the problem/challenge is to get successful websocket / stream initation.
Hello Stian,
answer to my post from 27th October #404 and the following posts:
- Postman gave no news fpr the solution. The only thing, that changed was “value” from “0” to “1” by “odp000c”, when i am opening the window.
- I have a solution: 2 Things are wrong and must be updated manually!
First: The ID of the device. If you import the things with the inbox, the given device-ID is “ABB12345”, but you must change the device-ID to the real ID of your device.
Second: The used channal. The used channel is by the import with the inbox always “ch0000”. You must change this to the channel, that you want to check.
I hope this helps.
With best regards
Martin
For manually created Things, the ID of the device and channel will be set to default values and need to be updated manually.
For autodiscovered Things, the device ID and channel will be set automatically. Note: From inbox you could search for a specific device ID and see each thing type recognized for the device ID.
Hello Stian,
all my Things were autodiscovered. Device ID an channel of the binary-switch were not set automatically. All other things (switches, raffstore switches, thermostats) were set automatically.
With best regards
Martin
Then it could be you have some old binding stuff/uncleaned cache, i.e. your thing autodiscovered as “dummy thing” which use predefined values. The binding is set up to set actual values from autodiscovery also for binary switch.
Were you able to find out, why these XMPP-streams are logged to your syslog? I currently have the same issue right now. My log (syslog.log and daemon.log) is totally full of these “trash”-entries.
Best regards.