New Enigma2 Binding

gdolfen · May 1, 2020, 7:48pm

Hello,
I developed a binding for enigma2 devices.
Because this is my first openhab contribution, please give me some hints if there is something missing.

Here is the PR: https://github.com/openhab/openhab-addons/pull/7514
You can download a snapshot-version of the binding here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.enigma2/2.5.5-SNAPSHOT/
Here you can find the readme: https://github.com/gdolfen/openhab-addons/blob/enigma2/bundles/org.openhab.binding.enigma2/README.md

Greetings
Guido

rlkoshak · May 1, 2020, 7:52pm

I recommend updating the title and tags to make it more clear what this new binding is all about. No one will be able to tell apart 100 postings all named “[New Binding]”. Maybe “New Enigma2 Binding”

gdolfen · May 1, 2020, 7:57pm

Sorry,I changed the title. Which taggings should I use?

sihui · May 2, 2020, 6:02am

Thank you very much for this great binding

I have tested the snapshot with a Vu+ Duo2 (firmware VTi 14.0.6): everything is working as expected.
I checked all channels, items and rules from your readme, no issues.

Is there any chance to change the duration of the screen messages like in the old openwebif action?

sendOpenWebIfNotification("main", "Hello World!\n\nThis is a message sent from openHab!", "WARNING", 10)

sihui · May 2, 2020, 6:05am

I would recommend: enigma2, openwebif, dreambox, vu+

sihui · May 2, 2020, 6:30am

Found a workaround:
sending an “EXIT” to the rcButton channel stops the message. In this way it is easy to implement this with a timer in a rule.

Edit:
One more suggestion: I would change the handler messages from INFO to DEBUG as it floods the openhab.log:

2020-05-02 08:23:36.403 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(MUTE)
2020-05-02 08:23:37.747 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_3)
2020-05-02 08:23:42.515 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_1)
2020-05-02 08:23:42.811 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_2)
2020-05-02 08:23:52.556 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_2)
2020-05-02 08:23:53.015 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_5)
2020-05-02 08:24:01.140 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(KEY_1)
2020-05-02 08:24:11.312 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(UP)
2020-05-02 08:24:15.721 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(EXIT)
2020-05-02 08:24:18.636 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(DOWN)
2020-05-02 08:24:22.083 [INFO ] [nding.enigma2.handler.Enigma2Handler] - sendRcCommand(EXIT)

gdolfen · May 2, 2020, 12:55pm

Thank you for your feedback.
The action now has three additional methods for sending infos, warnings and errors with a custom timeout. I also changed the handler logging to debug level. Can you try it out, please?

sihui · May 2, 2020, 3:16pm

Wow, lightning fast, thanks a lot!
Custom timeout is working and log is not flooded anymore.
Now I can put my old, no longer maintained openwebif action to rest
Good luck for your PR.

sihui · May 3, 2020, 5:24am

Found one little glitch overnight: if the receiver is switched to deep sleep you’ll get this in the log:

...
2020-05-03 04:31:20.548 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:31:35.561 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:31:48.623 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:32:01.711 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:32:14.799 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:32:27.887 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:32:40.975 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:32:54.063 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:33:07.151 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:33:20.239 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:33:33.327 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:33:46.415 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
2020-05-03 04:33:59.503 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://192.168.2.25/web/powerstate.
...

Although this message is correct because of deep sleep mode it floods the openhab.log with a warning every refresh interval.

gdolfen · May 3, 2020, 8:44am

I don‘t know the openhab way to deal with this.
I think there are the following alternatives:

Supress this log => there is no logging for Troubleshooting
Change the level to debug => you only get problem warnings in debug mode and it will flood the debug log every 5 seconds
Caching the log and print it only the first time ist occurs

In my opinion option 3 is the best one, but which level should use for it.

Are there any suggestions of other openhab contributors?

sihui · May 3, 2020, 9:01am

From a users perspective I would prefer option 2.

I don’t think that’s a problem: for example the zwave binding produces megabytes of log data within minutes in debug mode.

ggaljoen · May 3, 2020, 10:21am

Thank you @gdolfen for this new binding.

Just noticed my system ‘bouquet’ for the request does not respond in the timeout of 5 seconds, it needs more like 8 to 10 seconds.

2020-05-03 12:14:42.301 [WARN ] [nding.enigma2.internal.Enigma2Client] - Error on transmit http://vu-duo2/web/getallservices.

java.io.IOException: java.util.concurrent.TimeoutException: Total timeout 5000 ms elapsed

What further processing do you perform with this information anyway?

Ambo · May 3, 2020, 12:00pm

Thank you very much for this nice binding - works fine with vu+Solo2

One question to send info message with a rule:

rule "Enigma2_SendInfo"
when Item Enigma2_SendInfo received command
then
   Enigma2_Info.sendCommand("This is a info")
end

This would send “This is a info” for 30 sec.
Enigma2_Info.sendCommand(“This is a info”, 5)
should this have the effect to show the info only for 5 sec? it’s not working

I tried this in the rules, but no effect
actions.sendInfo(“Hello World”, 10)

sihui · May 3, 2020, 12:07pm

You will need something like this:

val actions = getActions("enigma2","enigma2:device:vuduo2")
  if(null === actions) {
   logInfo("actions", "Actions not found, check thing ID")
   return
  }
actions.sendInfo("Testmessage!",5)

druciak · May 3, 2020, 12:08pm

Log only when state is “online”, ignore when it is already “offline”.

But definitely debug level is the right one.

Ambo · May 3, 2020, 12:20pm

thank you very much - that really works fine
and thanks for this really quick answer !!!

gdolfen · May 3, 2020, 1:00pm

@sihui:
From a users perspective I would prefer option 2.

@druciak:
4. Log only when state is “online”, ignore when it is already “offline”.
But definitely debug level is the right one.

I changed the logging to debug level only if state is “online”, thanks for your advice.

@ggaljoen:
Just noticed my system ‘bouquet’ for the request does not respond in the timeout of 5 seconds, it needs more like 8 to 10 seconds.

I added a config parameter, so you can customize the timeout. But you should also change your refresh interval.

ggaljoen · May 3, 2020, 1:29pm

Timeout solved with the additional parameter!

Great improvement on the logging approach as well.

Do you plan the question input ‘getanswer’ ?

druciak · May 3, 2020, 3:52pm

With your changes I think nothing will be logged when the configuration is incorrect. It should be logged at least once at the beginning.

gdolfen · May 3, 2020, 4:15pm

@druciak:
With your changes I think nothing will be logged when the configuration is incorrect. It should be logged at least once at the beginning.

You are right. I fixed it with commit https://github.com/gdolfen/openhab-addons/commit/2ca982e190ac5fcf4a519c691ebe29e77267de98 (I hope so)