Tahoma Binding compatible with OH2

Hi Raphael,
of course I’ll add the support, since it is similar to roller shutter or awning thing it is quite easy.

I’ll let you know - I need to test it…
Thanks.
Ondrej

Hi Ondrej,
Thank you for your great help. The new version and configuration works fine for me.

Best regards,
Thomas

Hi Ondrej,

Since moving to 2.4.0-SNAPSHOT I the binding stops running after a while. Logfile shows:

2018-08-30 13:42:30.784 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:224) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:887) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:852) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:801) ~[?:?]
        at com.google.gson.Gson.fromJson(Gson.java:773) ~[?:?]
        at org.openhab.binding.somfytahoma.handler.SomfyTahomaBridgeHandler.getTahomaVersion(SomfyTahomaBridgeHandler.java:581) ~[?:?]
        at org.openhab.binding.somfytahoma.handler.SomfyTahomaBridgeHandler.updateGatewayState(SomfyTahomaBridgeHandler.java:552) ~[?:?]
        at org.openhab.binding.somfytahoma.handler.SomfyTahomaBridgeHandler.updateTahomaStates(SomfyTahomaBridgeHandler.java:324) ~[?:?]
        at org.openhab.binding.somfytahoma.handler.SomfyTahomaBridgeHandler.lambda$0(SomfyTahomaBridgeHandler.java:98) ~[?:?]
        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) [?:?]
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $
        at com.google.gson.stream.JsonReader.beginObject(JsonReader.java:385) ~[?:?]
        at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:213) ~[?:?]
        ... 15 more

and:

2018-08-30 13:56:49.282 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
        at org.openhab.binding.somfytahoma.internal.discovery.SomfyTahomaItemDiscoveryService.runDiscovery(SomfyTahomaItemDiscoveryService.java:123) ~[?:?]
        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) [?:?]

Using openHAB 2.3 stable on a RPI3.

Have you had this error before? Any chance you know what it is and how to fix it? At the moment my only fix is to restart openHAB.

Best regards,
Arjan

Hi Arjan, please try the latest version from here
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.somfytahoma/2.4.0-SNAPSHOT/org.openhab.binding.somfytahoma-2.4.0-SNAPSHOT.jar

Today in the morning I did last patches, so the provided exception doesn’t match the current version of code.
Of course I will try to do my best and fix this error.
Thanks
Ondrej

Hi Ondrej,

Thanks for your reply. For now I am back at 2.3.0-SNAPSHOT as this version was very stable in my setup. I keep checking the log-file. If 2.3.0 also stalls, I move to the latest 2.4.0-SNAPSHOT.

Best regards,
Arjan

Hey there, what a great binding!! I’ve a Connexon Box and some roller shutter and they are working fine with automatic discovery. Is there a change to add the gateway, rollershutter and and bridge in my things and items files? What syntax do I need to use? Thanks & Regards Jan

Hi,

I am glad to hear it! Here is the required info:

I hope you will find what you need.
Thanks.
Ondrej

Hey Ondrej_Pecta, that‘s exactly I searched for. Thanks a lot.

Hi Ondrej,
I’m having some trouble with the 2.4-SNAPSHOT version of your plugin. The “position” channel is missing for my roller shutters.
Update:
After some RTFM I found out, that you can use the Control-Channel to set the position, which works great. I have to update my item-links but this wont be a big deal.

Old Post content:

Long story:
I’ve been using a 2.3-SNAPSHOT version for the last 6 Months or so which worked well.
Yesterday I updated Openhab to 2.3.0 and also downloaded your latest 2.4.0 snaphot. I noticed that my roller shutters won’t react on changes to the sliders on my dashboard.
So I tried out some things and found out, that when I delete a roller shutter “thing” and add it again through the OH-Inbox, there is only a channel for control but none for position.
Is this a known problem? Do you have any idea on where to start to troubleshoot this?
Unfortunately I can’t get the 2.3.0-SNAPHOT working again because is says there is a unresolved dependency to google-gson, I remember I had this issue before but forgot how I fixed it :slight_smile: (I’m a java dev myself but -luckily- never had to deal with OSGI and its dependency management)
But I’ve found a 2.2.0-SNAPHOT version of your plugin in my downloads folder which still works (roller shutter position can be set), so I think this is not an general OH 2.3.0-Issue but something in your plugin.
If you like, I can open a bug for this, if you want to keep this thread clean.

Best regards and thanks for your great plugin
Benjamin

Hi Benjamin,
the latest version of this binding is already merged to master of OH2 plugins repo. Before merging I had to implement several changes to the binging according the valuable comments by other members.

Getting rid of “position” channel is one of them since it only duplicated the function of “control” channel. So I would advise everyone who wants to use the 2.4 version or newer to replace the “position” channel with the “control” one.
Ondrej

Hi Ondrej,
thanks for your reply. I have an other issue and I don’t know if you are aware of that:
Today I was experimenting with an issue that occurs if you send many control events in a short period of time. I have about 20 roller shutters and if I try to put them to a desired position all at once (through a OH-Rule) this never works for all shutters.
Example what I mean by rule:

if (Shutter_EG_State.state == "S") {
                sendCommand(EGKChe_SomfyRollerShutterPosition, 80)
                sendCommand(EGBehandlung_SomfyRollerShutterPosition, 80)
                sendCommand(EGWartezimmer_SomfyRollerShutterPosition, 98)
                sendCommand(EGBad_SomfyRollerShutterPosition, 80)
                sendCommand(EGEsszimmer_SomfyRollerShutterPosition, 80)
                sendCommand(EGWohnzimmerHof_SomfyRollerShutterPosition, 80)
                sendCommand(EGWohnzimmerStraE_SomfyRollerShutterPosition, 80)


}

When I check the log I see this error:
[WARN ] [oma.handler.SomfyTahomaBridgeHandler] - Apply command response: {"error":"Execution queue is full on gateway: #XXXXXXX (soft limit: 10)"}

If I use the Somfy-App to fire a (Somfy-)Rule all shutters work simultaneously. Maybe the Somfy-Rule is one Execution-Command and the rule gets resolved at the gateway itself?!

Do you know about this issue? Maybe are you already working on it?
I think a queue in your plugin could resolve this issue.

  • Put Items in the queue when commands arrive
  • Have an independent thread to check the queue every X ms
  • Try to send queue items to the somfy api one by one as long as no error is reported back from somfy
    – remove successfully sent items
  • (Have some extra delay if an error gets reported from somfy api to not hammer their api every 100ms)
  • Retry to send queue items to the api
    – Give up a queue item after a given amount of time or retries

Best regards
Benjamin

Hi Benjamin,

yes, we faced this soft limit with one user some time ago. In most cases there’s a workaround - just use an action group (scenario) and execute it instead of separate commands on each rollershutter.
Action groups are executed by one API call and therefore there is no problem with the throttling.

I know one queue would solve this, but it means a lot of refactoring I am unable to invest time in right now. I am thinking about a quick solution to aviod this soft limit - if the sending fails for this reason, I’ll try to sleep for 200ms and resend it again. I’ll give up after some unsuccessful attempts so the thread is not hogging and hammering their API forever.

If you want I can prepare a fix you can test.
Thanks
Ondrej

Hi Ondrej,
thanks for the hint with groups. I’ll give that a try. In my case I have 3 shutters wich require special values, for the rest of them the same value is okay. So I’ll make two groups (generic shutter and sleeping room shutter) and test if this solves my issue.

Thanks once again
Benni

Hi Ondrej,
its me again :slight_smile:

I was experimenting with getting the state of a roller shutter after it has been changed “manually” via its remote (and not your plugin). For me it looks like the somfy API does not reflect this changes automatically (the getEvents endpoint displays no events and even getStates does return the incorrect “core:ClosureState”).

After opening the Connexoon-App on my mobile the state got “magically” fixed on the getStates endpoint, so I tried out some things and somehow found out, that there is an endpoint “refreshAllStates” which does the trick.
As far as I can see you currently don’t use that endpoint.

  • Is there something wrong in my configuration, that refreshAllStates is required or is refreshing states of manually changed shutters currently not supported in your plugin?

Another issue I observed: If I send a new position command to a shutter while it is moving, the new position is not taken into account. Example: I send a position of “50” to the shutter and while it’s still moving I send “100”. The shutter now stops at 50%. Is something wrong in my setup, or does this currently not work?
Update: I found the cause of this issue in SomfyTahomaRollerShutterHandler#handleCommand if an other execution is currently running you don’t send the new command (unless the new command is a stop/my command). I think refactoring the IF-Condition to the following code may do the trick. I tested the “apply” endpoint with various “setPosition” commands and it looks like it works perfectly if you send new commands while the shutter is still moving…

   if (executionId != null && cmd.equals(COMMAND_MY)) { 
       /* cancel ...*/ 
    } else { 
     /*sendCommand*/ 
   }

Best regards and thanks once again :smiley:

Hi, Ondrej,
First of all also from my side a big thank you for that work! I have a lot of devices and so far all worked fine. Now I own Enocean driven window handles, which are not supported. Do you think, you could enable this item too? Here is an extract of my log:

2018-10-11 21:03:52.524 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: WindowHandle
2018-10-11 21:03:52.524 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { }
2018-10-11 21:03:52.525 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=‘core:ThreeWayHandleDirectionState’, type=3, value=tilt}
{name=‘core:RSSILevelState’, type=1, value=80.0}

2018-10-11 21:13:47.444 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: WindowHandle
2018-10-11 21:13:47.445 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { }
2018-10-11 21:13:47.447 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name=‘core:ThreeWayHandleDirectionState’, type=3, value=closed}
{name=‘core:RSSILevelState’, type=1, value=80.0}

So there are 3 possible values for those sensor type window handles: open, closed, tilt

Best regards, Oliver

Hi,

support for the Window Handle has been added. The latest snapshot is as usual downloadable here:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.somfytahoma/2.4.0-SNAPSHOT/
Thanks.
Ondrej

Hi,

I have no problem with updating states with Somfy Tahoma. It seems this is a Connexoon specific behaviour since Tahoma is aparently updating states reliably.
Regarding the second issue you mentioned - it is a feature. I have changed the behaviour to this one because otherwise you can put a lot of commands to queue with slider (dimmer).
Maybe the best solution might be to call STOP and then call the new APPLY, radher than put the next APPLY command to the Tahomalink queue in case the roller shutter is moving.

Ondrej

I’ll check the updating of states again tomorrow.
Regarding multiple position changes in a row:
Do you think its necessary to send a STOP? I just tried it out with the following if condition:

            String cmd = getTahomaCommand(command.toString());
            if (cmd.equals(COMMAND_MY)) {
                String executionId = getCurrentExecutions();
                if (executionId != null) {
                    //Check if the rollershutter is moving and my is send => STOP it
                    cancelExecution(executionId);
                } else {
                    sendCommand(COMMAND_MY, "[]");
                }
            } else {
                String param = cmd.equals(COMMAND_SET_CLOSURE) ? "[" + command.toString() + "]" : "[]";
                sendCommand(cmd, param);
            }

That works great even when I do like 10 changes in a row. Even if I switch directions it works.
Calling the getEvents - Endpoint from tahomalink delivers a truckload of events but everything is working. I can see some Events of this kind:

 {
    "name": "ExecutionStateChangedEvent",
    "ts": "1539465326987",
    "setupOID": "81284ce3-ce3c-4200-b68b-b61ef3535ee8",
    "execId": "6f48ae6d-3624-6026-71d4-0855b265b693",
    "newState": "5",
    "failureType": "106",
    "failureName": "CMDCANCELLED",
    "ownerKey": "81284ce3-ce3c-4200-b68b-b61ef3535ee8",
    "type": "1",
    "subType": "1",
    "oldState": "3",
    "failedCommands": {
      "command": {
        "deviceURL": "io://0806-9473-8878/12518651",
        "failureType": "106",
        "rank": "0"
      }
    }
  }

Seems they are taking care of cancelling commands without the need of explicit applying stop or canceling an execution.

Regarding the MY-Command you can see in my code snippet:
I did some further changes because currently it is not possible to call MY if the corresponding OH-Item is of type Rollershutter. But Rollershutter-Items support the command “MOVE” which I mapped to my. I also avoided magic strings by referring to the UpDownType, PercentType and StopMoveType of the OH-Commands.

Maybe I can open an Issue on your github repo or what do you think is the best way to discuss things like this?

Best regards Benjamin

Hi Benjamin,

I’ve spent some time testing the current behaviour and you are right! It seems they’ve changed something on the server side, because they are automatically sending cancel events instead of queuing the commands.
I am pretty sure it was working differently two years ago when I was testing the first version of OH1 binding.

I’ll include your snippet in the main branch.
I do not know what do you mean by " it is not possible to call MY if the corresponding OH-Item is of type Rollershutter". It was working and it is still working, there is no need to send MOVE commands, even if I use your snippet or not.

Thanks.
Ondrej

Hi Ondrej,

regarding MY and MOVE:
I’ve an item “EGKChe_SomfyRollerShutterPosition” (still called “position” but thats just because I was too lazy to recreate each item) which is linked to the command channel of one of my rollershutter things. When this item is set to type “Rollsershutter” I’m not able to send a “MY” command through the OH-Rest API, if I try to send a POST command to this item.
I get an http error code 400 back from the OH-Rest API. In the logs you can find the following:

[WARN ] [rest.core.internal.item.ItemResource] - Received HTTP POST request at ‘items/EGKChe_SomfyRollerShutterPosition’ with an invalid status value ‘MY’.

I digged around the code and found out that ItemResource calls item.getAcceptedCommandTypes() to verify if a command is allowed/supported.
For the TypeRollershutter (from org.eclipse.smarthome.core.library.items) the method getAcceptedCommandTypes returns a list of the following supported Commands: UpDownType,StopMoveType, PercentType and RefreshType

That means everything that could not be mapped to one of this 4 Types (3 of them are Enums with multiple values) is rejected. Thats why I used the “MOVE” command of the StopMoveType Enum, it is currently not supported by your plugin but seems to be the best choice to implement Somfys “My” position.

If I remember right, in OH 2.0 or 2.1 it did not make sense to set the item Type to Rollerhutter because no slider was displayed in BasicUI but only UP and DOWN buttons, this has been changed now, so that item type Rollershutter seems to be the best for an rollershutter and you don’t need to use Dimmer any more :slight_smile:

Another more general question is, if one should replicate the behaviour of the Somfy Remote regarding “MY”. Somfy just didn’t wand to have an additional button on the remote for STOP, but in reality MY and STOP are two completely different things. One could argue if I send “MY” to an rollershutter I don’t care if it is currently moving or not, I just want it to go to its stored position. If one would like to stop a moving rollershutter the STOP command will always be the right choice.
I hope you somewhat get what I’m trying to say, I read a lot of English but don’t talk/write to much :slight_smile:

Best Regards
Benjamin