2n Helios IP Vario binding

@bernd_d You do need to set it to “Secure TLS” as connection type, and “Basic” for the authentication. The username/pwd you set in the Account 1 page needs to be supplied to the Thing configuration (via .things or paper UI)

With the Gold license, you see Monitoring and Control columns on the configuration page, and there are a bunch of additional privileges that can be set, like System API, …

Just changed it to Secure TLS and Basic without any difference. I keep getting the above error message.
Firmware is 2.21.2.30.5 currently.

@bernd_d mhhh… Ok, I think I have found the issue.

You do not have the System API available for configuration, right?

In the initialisation phase of the Helios Thing Handler I do fetch “info” from the device using the System API. If you do not have access to that API, that initialisation will fail.

I need to check if we can replace that with a call that is part of an API from the Basic license

[Edit] You do see that firmware , serial number and other info in paperUI? that means you do have access to the System API, and thus the problem must be something else

@kgoderis
I tried too to insert my Helios IP Vario (without any special license) in my Openhab2 system with the Helios binding and this is what I found out:

1 - I set the Services-HTTP API section of my device in this way

and

2 - I decided to create a .thing configuration file, I copied the example from the documentation and I looked in the Paper UI to see if the Helios thing would appear, but the system could not find it. I tried with the automatic search and the thing was discovered, so I noticed a little problem in the thing configuration example of the documentation

Thing helios:ipvario213:gate [ipAddress=“192.168.0.14”, username=“test”, password="**********"]

I changed it in this way (I deleted the word Thing at the beginning and I changed “ipvario213” with “ipvario221”)

helios:ipvario221:gate [ipAddress=“192.168.0.14”, username=“test”, password="**********"]

and in this way my thing was recognized using the file configuration way too

But the status remains “offline - communication errors”, sometimes it seems to change but after less than one second comes back to “offline - communication errors”, the log gives me this (it seems to me the same that occurs to bernd_d)

2018-02-09 08:56:47.782 [ERROR] [ding.helios.handler.HeliosHandler221] - An error occurred while communicating with the Helios IP Vario ‘helios:ipvario221:gate’: code ‘8’, param ‘null’ : ‘invalid authentication method’
2018-02-09 08:56:46.609 [ERROR] [ding.helios.handler.HeliosHandler221] - An exception occurred while processing an event : ‘null’
java.lang.NullPointerException: null
at org.openhab.binding.helios.handler.HeliosHandler221$3.run(HeliosHandler221.java:699) [231:org.openhab.binding.helios:2.3.0.201802061951]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]

I agree that, if possible, it would be great if information about states would be available without the need of any special license.

Bye.

@emme-oh You need to set “Basic” authentication instead of “Digest”

@kgoderis I had already set “Basic” before for the Logging API but I had left “Digest” for Camera API because my device hasn’t any camera.
Anyway now I’ve set “Basic” authentication both for Logging and Camera API (I can’t change anything else with my license)

and I added Camera and UID Access too to the user privileges even if my device doesn’t have those features (I can’t add anything else with my license)

The result in the Paper UI is the same as before (Status: OFFLINE - COMMUNICATION_ERROR 8:null:invalid authentication method) and the log is this one

2018-02-09 10:50:31.860 [ERROR] [ding.helios.handler.HeliosHandler221] - An error occurred while communicating with the Helios IP Vario ‘helios:ipvario221:gate’: code ‘8’, param ‘null’ : ‘invalid authentication method’
2018-02-09 10:50:31.869 [ERROR] [ding.helios.handler.HeliosHandler221] - An exception occurred while processing an event : ‘null’
java.lang.NullPointerException: null
at org.openhab.binding.helios.handler.HeliosHandler221$3.run(HeliosHandler221.java:699) [231:org.openhab.binding.helios:2.3.0.201802061951]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]

I know it is redundant but I write again that my Helios IP Vario has, at the moment, no special license (no Gold or enhancen license).

@emme-oh The reason it does not work in your case is that the binding needs “Basic” on the System API, which is the one I query in order to validate that it is a Helios device. Now, the weird thing is that this is the same API that is used to query or the serial number, HW version and so forth, so it could be that some part of the API is open for any authentication method. If so, then I have to rewrite part the binding in order to support other HW versions or licenses.

K

@emme-oh in the screenshot I do see another error (“pull request already active”). Can you provide me with more log data, preferably with the binding set to the TRACE logging level.

Tx

Hi @kgoderis,
yes, I do see the firmware, serial number etc within the paper UI (show properties). I activated DEBUG level. After creating the thing via PaperUI this happens:

2018-02-09 14:42:02.842 [DEBUG] [ding.helios.handler.HeliosHandler221] - Initializing the Helios IP Vario handler for 'helios:ipvario221:2f3f4a5b'.
2018-02-09 14:42:03.807 [DEBUG] [ding.helios.handler.HeliosHandler221] - Fetching the configuration of the Helios IP Vario 'helios:ipvario221:2f3f4a5b' 
2018-02-09 14:42:03.879 [DEBUG] [ding.helios.handler.HeliosHandler221] - The subscription id to pull logs from the Helios IP Vario 'helios:ipvario221:2f3f4a5b' is '415555413'
2018-02-09 14:42:03.987 [DEBUG] [ding.helios.handler.HeliosHandler221] - An error occurred while communicating with the Helios IP Vario 'helios:ipvario221:2f3f4a5b' : code '8', param 'null' : 'invalid authentication method'
2018-02-09 14:42:04.012 [ERROR] [ding.helios.handler.HeliosHandler221] - An error occurred while communicating with the Helios IP Vario 'helios:ipvario221:2f3f4a5b': code '8', param 'null' : 'invalid authentication method'
2018-02-09 14:42:13.908 [ERROR] [ding.helios.handler.HeliosHandler221] - An exception occurred while processing an event : 'null'
java.lang.NullPointerException: null
	at org.openhab.binding.helios.handler.HeliosHandler221$3.run(HeliosHandler221.java:699) [253:org.openhab.binding.helios:2.3.0.201802061951]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-09 14:42:13.912 [ERROR] [ding.helios.handler.HeliosHandler221] - An exception occurred while processing an event : 'null'

@emme-oh @bernd_d If I find the time over the weekend I will alter the Helios binding to include additional TRACEing so that I can better understand how your devices/licenses work. You understand it was developed against a Vario with Gold, but we will get there.

@kgoderis OK Karel
I tried to enable the log TRACE level following the logging documentation page:
in the Karaf Console I wrote

log:set TRACE org.openhab.binding.helios

and now my log file is a list of repetition of this error

2018-02-09 18:22:15.610 [ERROR] [ding.helios.handler.HeliosHandler221] - An exception occurred while processing an event : 'null’
java.lang.NullPointerException: null
at org.openhab.binding.helios.handler.HeliosHandler221$3.run(HeliosHandler221.java:699) [231:org.openhab.binding.helios:2.3.0.201802061951]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]

About the binding: it was, and it is, clear that this binding was created for devices with the Gold license (and there are already lots of good feedback from people using it); in my view now we’ve made a try to test it with devices without Gold or any other special license just to understand how this binding would work in these cases, and at the moment we have found out that there are some problems to get the thing online. Maybe it could be a good idea to implement the documentation about what we’ve found (because I’m not a IT professional and I don’t have any special talent in programming, if it’s needed I could try to help to modify the documentation).
Said that, I’ll be surely happy, and maybe some more people too, if and when you or other contributors will have the time to try modify the binding in order to give as much functionalities as possible to devices without any special license too.
So, at the moment, thank you for your efforts and for the results you’ve already achieved.
Bye.

@kgoderis I totally understand that it was developed for another device with another license. I’d really appreciate it and I guess the community would be very thankful if you like to open this binding to a broader user base. I can only second @emme-oh with a big thank you for the efforts so far.
So happy to help with testing. Let me know what Trace information you need with the new binding to get there.

Bernd

@kgoderis thank you for providing an updated .jar. Totally different experience :slight_smile:
With the latest version I do get a stable online thing, although just one error message still pops up once:

2018-02-11 20:55:23.348 [ERROR] [ding.helios.handler.HeliosHandler221] - An error occurred while communicating with the Helios IP Vario 'helios:ipvario221:264ca80c': code '8', param 'null' : 'invalid authentication method'

Tried to link items “device state”, “call state” and “keypress” but do not see the status of the device (within the Entrycom gui the log say’s “started”). BUT I see the call state !! :+1:
btw: Upgraded also to a newer firmware 2.22.031.8.

Bernd

Edit: Just noticed that in Paper UI I was able the select the device state correctly … ? Shouldn’t this state be filled automatically?

@bernd_d Can your provide some more TRACE logging around this error you still see? Need to figure out where and when this happening.

The device state itself, as reported, by the device is rather silly. It does not provide anything meaningful, but you should be able to set that yourself, so I need to fix that in the ESH-INF xml.

@kgoderis Hello, I tried too the last .jar file you sent and it works much better.
My Helios thing gets online and already I can use several channels, I set some items and they get information when some events happens.
In detail, this is what happens with my system:

  • the channels those do provide information to my items are keypressedstamp, keyreleasedstamp, callstate, callstatestamp, calldirection, switchstate, switchstateswitch, switchstateoriginator, switchstatestamp;

  • the channels those don’t provide information to my items are keypressed, keyreleased, all channels related to card (my Helios has no card reader), all channels related to code (my Helios has no keypad), all channels related to audiolooptest (my Helios has no Gold license), all channels related to motion (my Helios has no video camera), all channels related to noise and all channels related to devicestate.

Some of the channels those in my system doesn’t work appear gray in the PaperUI, as you can see in the attached screenshot

Considering that without Gold license my system can probably only get information from the Helios, I could say that the channels provided by this binding (once all of them will work) already cover all the useful information my system needs.

I think that one good improve (but it only affects who commands more switches with just one Helios) might be to provide different channels for each switch instead to use the switchstateswitch channel; so every switch could have the three related channels (switchstate1, switchstateoriginator1 and switchstatestamp1; switchstate2, switchstateoriginator2 and switchstatestamp2; etc.). At the same time could be a good improve (but it only affects who has a device with more than one button) might be to provide different channels for each button; so every button could have the four related channels (keypressed1, keypressedstamp1, keyrelease1 and keyreleasestamp1; keypressed2, keypressedstamp2, keyrelease2 and keyreleasestamp2; etc.).

I send you soon my log file with TRACE level.

Bye.

Different channels per button or switch is not an ideal situation, because that is 1) not how the Helios is reporting back information, and 2) you can not predict the number of buttons on a device. I do add channels at runtime dynamically for the switches though (that is, to control them), but it requires the Gold license

Keypressed should return something, so I will investigate. It does return a string with the number of the key pressed (does not necessarily equals the number you read on the button, but that is Helios’ funky implementation).

@emme-oh Marco, had a very quick look at your logs, and you do receive the KeyPressed events, not sure what is wrong here

12-Feb-2018 14:04:17.218 [TRACE] [rg.openhab.binding.helios.handler.HeliosHandler221] - pullLog() Response: {"events":[{"id":361,"tzShift":60,"utcTime":1518440662,"upTime":1106962,"event":"KeyPressed","params":{"key":"%3"}}]}
12-Feb-2018 14:04:17.219 [TRACE] [rg.openhab.binding.helios.handler.HeliosHandler221] - Successfully pulled log entries from the Helios IP Vario 'helios:ipvario221:gate'
12-Feb-2018 14:04:17.234 [DEBUG] [rg.openhab.binding.helios.handler.HeliosHandler221] - Received the event for Helios IP Vario 'helios:ipvario221:gate' with ID '361' of type 'KeyPressed' on 1970-01-18T14:47:20

With respect to “code”, that does not have to do with an internal extension/device of the Helios, but with a code you enter on the keyboard (e,g. sequence of 4 digits and the * (or the # key, do not remember))

@kgoderis I’ve looked too into the log file before and, even if I’m absolutely not an expert, it seemed to me strange too that I did’t get any value for the keypressed channel. The reasons are:

  • the channel keypressedstamp works, so everytime I press a key I get the timestamp (so, more or less, indirectly I can have the information about the fact that a key was pressed and I guess that it can exclude a license issue);

  • in the log file I could find informations about KeyPress events (but there are info about KeyReleased events too).

In the screenshot I attached to my previous message, it is possible to see how in Paper UI (thing configuration) are four channels those are gray colored and those don’t work (they appeared in that way even before I set any item or sitemap file): two of them are channels “card” and “code” (I haven’t explain myself really good before: my device has no card device and no keypad so I expected to see these channels not working in my system and surely I can’t make any test with them) and the other two are channels “keypressed” and “keyreleased” (I think that, because I’ve seen something related to them in the log file, I could have a chance to see these two channels working).

About the idea of separate channels for different button or switch, I’ve already imagined that the structure of the binding was probably reflecting the way the Helios is reporting the information. I wrote it because in my opinion it would make easier the user experience (at least mine, but I guessed somebody else could agree), I think I can arrange some rules in my system to reach my objective but I thought it could be good to see what other user would think about this idea.
In my knowledge, for Helios IP Vario the maximum number of switches is 4, on the other hand I know that the number of buttons is determined by the number of extensions modules used and it depends on the single situation (but the basic scenario, without extension modules, is maximum 6 buttons). In another binding that I currently use, the Opensprinkler binding https://docs.openhab.org/addons/bindings/opensprinkler/readme.html, a similar situation has been resolved creating a lot of, often unused, channels.

Anyway, some days ago the Helios binding was just for devices wit Gold license and now its functionalities are almost available for all the Helios devices! Thank you for your work. Bye.

@kgoderis I just noticed that I had made a mistake in my item file, it affected the keyreleased and the keyreleasedstamp channel. Now that It has been corrected, the keyreleasedstamp works as expected but the keyreleased keeps on not working at all.
I’ll modify right now my previous message including this correction and the keypad misunderstanding one.

The channels those still don’t work, and I would expect to see working, are:

  • keypressed and keyreleased (the Openhab log file and the Helios event list provide information about them so I don’t think here exists any license issue);

  • devicestate and devicestatestamp (but i’ve seen the post where the state as reported by the device is described as silly :slight_smile: ).

Moreover, I don’t know if the channels noise and noisestamp can have chance to work with my (without Gold licence) device. Do have they?

I noticed one more thing looking inside my helios log file: the timestamp information provided inside the log messages (in those I already sent you too) is completely wrong and that affects all my stamp channels (my Openhab2 system and my Helios IP Vario are both correctly synchronized with the actual time and shows the right time and date). It’s not the most important issue right now but, because I’ve found it, I believe it’s good to signal it.

Bye

Hi Everyone, I would like to buy the new 2N IP solo as intercom for my home. I have a KNX system working together with openhab2, I just wondered if I can use the existing openhab helios binding also for the 2N IP solo?

Or do you guys now a better way to integrate an intercom with KNX and/or openhab?

Thanks!