New Enigma2 Binding

Tags: #<Tag:0x00007f616faad020> #<Tag:0x00007f616faaceb8> #<Tag:0x00007f616faac2d8>

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

4 Likes

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”

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

Thank you very much for this great binding :+1:

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? :innocent:

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

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

1 Like

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)

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?

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 :heart_eyes:
Good luck for your PR.

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.

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

  1. Supress this log => there is no logging for Troubleshooting
  2. Change the level to debug => you only get problem warnings in debug mode and it will flood the debug log every 5 seconds
  3. 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?

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.

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?

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 :frowning:

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

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)
1 Like
  1. Log only when state is “online”, ignore when it is already “offline”.

But definitely debug level is the right one.

1 Like

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

1 Like

@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.

2 Likes

Timeout solved with the additional parameter!

Great improvement on the logging approach as well.

Do you plan the question input ‘getanswer’ ?

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

@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)