Tahoma Binding compatible with OH2

Ondrej_Pecta · October 14, 2018, 8:38am

Yes, in fact we need to have four buttons, but I’ve replicated the behaviour of Somfy remote to Rollershutter iterm, so now it behaves exactly as the physical remote (Smoove, …). The STOP command is issued when the device is moving and MY when it’s stopped.

I do not see any problem with that since the Somfy users are used to control it this way
Ondrej

BenniG · October 14, 2018, 8:59am

I support what you say, we Somfy users are used to use the remote that way. But for automation (via a rule) it would be a nice feature to set the Rollershutter to its stored position regardless of its current state. I think its very unlikely that the shutter is currently moving when a rule is fired but it could result in some quirks from time to time e.g. when the sun is glaring and a brightness-sensor is triggered shortly after the user decided to close the shutters through Basic UI.
But its somewhat of a breaking change, so there is more weight on the “leave the current behavior” side

Ondrej_Pecta · October 14, 2018, 10:18am

In this case I fully agree. If you have any idea how to improve this, of course we can discuss it
As far as I know the Tahomalink UI doesn’t have the feature of setting MY position on roller shutters either, so we are a bit advanced in OH2

BenniG · October 14, 2018, 7:11pm

I think the easiest solution would be to define a new command. You could either

Keep the current meaning of MY and introduce GO_MY (or something similar)
Change the current meaning of MY to going to the Somfy-My-Position and introduce a command e.g. STOP_MY to address the old behavior.

But as long as the items are of type Rollershutter none of this commands would be accepted. I tried sending “MY” through a rule and got the following error in the log:

[WARN ] [rthome.model.script.actions.BusEvent] Cannot convert 'MY' to a command type which item 'EGEsszimmer_SomfyRollerShutterPosition' accepts: [UpDownType, StopMoveType, PercentType, RefreshType]

What Item-Type do you usually use? I tried Rollershutter (see error above), Dimmer which also does not accept “MY” (similar error in the logs) and String which doesn’t give an error but still does not work (nothing happens)

I also took a look in my sitemap and have to revert what I said earlier:

I think I mixed up something. If you use a Default definition for a Rollershutter item in a Sitemap you still get UP/DOWN/STOP Buttons. Using a Slider Definition did and still does the trick.

Best regards
Benjamin

BenniG · October 14, 2018, 8:03pm

By the way. Here is what I meant by “no more magic strings” and referring to UpDownType, StopMoveType and so on:
e.g. for SomfyTahomaRollershutterHandler

    private static final Map<Object, String> commandMap = new HashMap<>();

    static {
        commandMap.put(StopMoveType.MOVE, COMMAND_MY);
        commandMap.put(StopMoveType.STOP, COMMAND_STOP);
        commandMap.put(OnOffType.ON, COMMAND_UP);
        commandMap.put(OnOffType.OFF, COMMAND_DOWN);
        commandMap.put(UpDownType.UP, COMMAND_UP);
        commandMap.put(UpDownType.DOWN, COMMAND_DOWN);        
        commandMap.put(PercentType.class, COMMAND_SET_CLOSURE);
    }

    /**
     * Map the given OH / EclipseSmarthome command to a Somfy command name.
     * Should be extracted to SomfyTahomaBaseThingHandler and signature should include the commandMap of the specific handler
     **/
    private String getTahomaCommand(Command command) {

        String mappedCommand;

        if (command instanceof Enum) {
            mappedCommand = commandMap.get(command);
        } else {
            mappedCommand = commandMap.get(command.getClass());
        }

        if (mappedCommand != null) {
            return mappedCommand;
        }
        throw new IllegalArgumentException("Command " + command.toString() + " of type " + command.getClass().getCanonicalName() + " is not supported on thing " + this.getThing().getLabel());
    }

Static initializer just for shortening purpose: the map could also be a field and get populated in the constructor. Or you could introduce a new abstract method getCommandMap to SomfyTahomaBaseThingHandler which needs to be implemented and returns the Map for a specific class.

Maybe you like it
I can offer some help in refractoring, if you like.

WallE · October 19, 2018, 2:52pm

Hi to you all! I’m a Newbie with openHAB, so far operating my io shutters only via Tahoma box.
So, many thanks @Ondrej_Pecta, for your tahoma binding, great stuff! Got it running and works just fine!

I was wondering: is there a possibility to address the tahoma box directly via the local(home)network, instead of going via Tahoma Webaccount?

tkaor · October 25, 2018, 7:39pm

Hello Ondrej and Benjamin,
I also have the problem with the Connexoon box that the current position is not updated. e.g. when the remote control is used or even if I send a STOP command during movement within openhab. I’m using Somfy io shutters as well as Velux rollershutters.

You are talking about endpoint “refreshAllStates”.
Is this something you can integrate into the binding?
Is it possible to trigger the refresh manually wihtin e.g. a rule? If yes, can you provide a short code snippet?

I’m also happy to help with testing if you provide me a new binding. As mentioned I can test it with the Connexoon, Somfy io and Velux rollershutters.

Thanks for your help.

Best regards,
Thomas

vossivossi · October 25, 2018, 7:51pm

Same for me with Connexoon box and 8 awnings from Markilux. Every new command seems to be ignored during movement. And position changes by remote control are not reflected correctly in OH.

BenniG · October 25, 2018, 8:15pm

Can you check, if the position is updated when you open the Connexoon-App on your mobile? Just open the app and do nothing in it, especially don’t move the shutter through the Connexxon-App). It takes some time but after a few minutes the position should be correct again in Openhab.

I think it should be possible to include a call to this endpoint every few minutes in Ondrejs plugin. If Ondrej doesn’t have time to do it himself I’ll check if I can submit a pull request to openhabs github-repo. (But I don’t know how the openhab team would like to have their pull requests, so maybe its more effort to satisfy their requirements than to incorporate the change)

Ondrej_Pecta · October 25, 2018, 8:52pm

Hi,

the latest version from pull request already fixes the commands ignoring.
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

The 2.4.0-SNAPSHOT version introduces two different ways how to get new states

using listening to the events (similar to Tahoma mobile app behaviour), when events are polled from cloud every {X} seconds. Default is 30s and you can set it even lower (refresh parameter), 10s works fine as well.
using getStatus command for refreshing state from cloud every {X} seconds when no event got from a device. Default is 300s, you can try to set it lower (statusTimeout parameter), but I do not recommend to set it under 30s or even lower than event polling interval.

If connexoon still refuses to update its state without refreshAllStates, the correct fix would be to autodetect the Connexoon bridge as new thing (bridge) and send refreshAllStates command before getting states only for Connexoon bridge. I do not want to spam TahomaLink API from Tahoma devices when only Connexoon requires this behaviour.

If so - we need to distinguish Tahoma and Connexoon devices during discovery. If someone with Connexoon could provide me with debug info from discovery we can move further.
Thanks
Ondrej

BenniG · October 26, 2018, 2:34am

I’ve included the complete response of getSetup getSetup.json (51.5 KB)

In the features section connexxon is mentioned and the gateway has a type and subtype. Hopefully there is something that differs from your tahoma box but is the same for all connexxon boxes

Best regards
Benjamin

Ondrej_Pecta · October 26, 2018, 7:09am

Thanks, it seems that your Connexoon gateway identifies itself as

"type":34, "subType":3

and

"features":[{"name":"connexoon-window","source":"GATEWAY_TYPE"}]

My TahomaBox identifies itself as

"type":15, "subType":14

and

"features":[  
      {  
         "name":"tahoma-security",
         "source":"GATEWAY_TYPE"
      },
      {  
         "name":"tahoma-premium",
         "source":"GATEWAY_TYPE"
      }
   ]

Please could someone else share his getSetup response?
BTW: Even TahomaLink forces state refresh by calling endpoint

/enduser-mobile-web/enduserAPI/setup/devices/states/refresh

I can add this call before getStates invocation and you could try if it helps to solve your problem…

Thanks.
Ondrej

BenniG · October 26, 2018, 7:42am

The easiest way to do this it to create a html file with the following contents:

<form method="POST" action="https://www.tahomalink.com/enduser-mobile-web/externalAPI/json/login" target=_blank>
Email:<br>
  <input type="text" name="userId" value=""><br>
  Password:<br>
  <input type="password" name="userPassword" value=""><br>
  <input type="submit">
</form>

Open this file in a browser and enter your email and password for connexoon and hit submit. As you can see in the form action this information is directly sent to the tahomalink domain owned by somfy. Nobody else can get your credentials.

After hitting submit you should see some JSON result with success: true and some information of the currently used somfy environment e.g. version": “2018.5.4.2-5”, “environment”: “ENV1-PROD101”,

To get your setup you can then just call https://www.tahomalink.com/enduser-mobile-web/externalAPI/json/getSetup

Your setup contains the address information you provided while registering at Somfy, I would recommend to remove this information

tkaor · October 26, 2018, 7:02pm

Hello Ondrej and Benjamin,
I also made the following test:

Change the rollershutter with the remote control
Wait several minutes and check if the new state is reflected in Openhab
The new state was net set in Openhab
Open the Connexoon Window app (without pressing any button in the app)
The correct postion gets updated in Openhab

As mentioned by Benjamin after opening the app the correct state is shown in Openhab.

I also read the getSetup response from my Connexoon (thanks for your guideline):

gateways
0
gatewayId	“0808-8597-0717”
type	34
subType	3
placeOID	“793fd003-ec59-4bcb-a631-c78d0c41a523”
alive	true
timeReliable	true
connectivity
status	“OK”
protocolVersion	“2018.5.4”
upToDate	true
updateStatus	“UP_TO_DATE”
syncInProgress	false
functions	“INTERNET_AUTHORIZATION,SCENARIO_DOWNLOAD,SCENARIO_TELECO_LAUNCHING,INTERNET_UPLOAD,INTERNET_UPDATE,TRIGGERS_SENSORS”
mode	“NO_AUTO”

features
0
name	“connexoon-window”
source	“GATEWAY_TYPE”

I hope this helps.

Have a nice weekend.
Thomas

Ondrej_Pecta · October 26, 2018, 9:41pm

Hi, could you test it with this version, please?
https://www.dropbox.com/s/mji5h7no6gl1t0x/org.openhab.binding.somfytahoma-2.4.0-SNAPSHOT.jar?dl=1

Wait at least 5 minutes (default statusTimeout value), it might be working now…

thanks.
Ondrej

tkaor · October 29, 2018, 6:35pm

Hello Ondrej,
Thank you very much for the new version. Unfortunately it is still not updating the position when the rollershutter was moved by the remote control. But I noticed that after opening the Connexoon app the position is also wrong for a short time. Only after a few seconds I see the right position in the app as well as in Openhab. It seems that the app sends a special command to the Connexoon hardware to get the current position. I hope you have any idea which command must be send by the binding to update the rollershutter positions.

Best regards,
Thomas

BenniG · October 29, 2018, 8:28pm

For me it worked sometimes and sometimes not?!
I watched the Somfy API while also checking the state in openhab.
The new (correct) state appeared quickly in the Somfy API but it got not reflected in Openhab, even though the plugin retrieved the state?!

I see the following log entries

2018-10-29 21:22:34.215 [TRACE] [oma.handler.SomfyTahomaBridgeHandler] - Response: {"devices":[{"label":"IO (11370222)","deviceURL":"io://0806-9473-8878/11370222","shortcut":false,"states":[{"name":"core:StatusState","type":3,"value":"available"},{"name":"core:ClosureState","type":1,"value":92}],"available":false,"enabled":false,"type":1}],"events":[]}
2018-10-29 21:22:34.464 [TRACE] [oma.handler.SomfyTahomaBridgeHandler] - Login response: {"success":true,"version":"2018.5.4.2-5","environment":"ENV1-PROD101","events":[]}
2018-10-29 21:22:34.465 [DEBUG] [oma.handler.SomfyTahomaBridgeHandler] - SomfyTahoma version: 2018.5.4.2-5
2018-10-29 21:22:34.466 [DEBUG] [.handler.SomfyTahomaBaseThingHandler] - Getting cached state: null for url: io://0806-9473-8878/11370222

But I still get 100 as closure state on the REST-API and on the Basic-UI. I don’t know why this happens?

MaGi · October 30, 2018, 10:56am

Hello Ondrej

I am owner of a Connexoon Box, and using your binding for Velux windows/rollershutters/screens and Somfy io rollershutters/awnings/exteriorscreens. Too, I have Somfy io lightsensors and temperaturesensors.

Would it be possible to support temperaturesensors, as well?

2018-10-30 09:48:29.749 [INFO ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: TemperatureSensor
2018-10-30 09:48:29.750 [INFO ] [very.SomfyTahomaItemDiscoveryService] - If you want to add the support, please create a new issue and attach the information below
2018-10-30 09:48:29.751 [INFO ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { }
2018-10-30 09:48:29.751 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name='core:StatusState', type=3, value=available}
{name='core:RSSILevelState', type=2, value=88.0}
{name='core:TemperatureState', type=2, value=21.80000000000001}

2018-10-30 09:48:29.753 [INFO ] [very.SomfyTahomaItemDiscoveryService] - Detected a new unsupported device: TemperatureSensor
2018-10-30 09:48:29.753 [INFO ] [very.SomfyTahomaItemDiscoveryService] - If you want to add the support, please create a new issue and attach the information below
2018-10-30 09:48:29.753 [INFO ] [very.SomfyTahomaItemDiscoveryService] - Supported commands: { }
2018-10-30 09:48:29.753 [WARN ] [very.SomfyTahomaItemDiscoveryService] - Device states:
{name='core:StatusState', type=3, value=available}
{name='core:RSSILevelState', type=2, value=76.0}
{name='core:TemperatureState', type=2, value=21.900000000000034}

Thanks in advance.

Regards,
Manfred

Ondrej_Pecta · October 30, 2018, 9:22pm

Hi,

thanks for the logs, I’ll add the support and let you know - I need you to test it.
Thanks.
Ondrej

Ondrej_Pecta · October 30, 2018, 10:01pm

Hi,

could you please test this version?
https://www.dropbox.com/s/mji5h7no6gl1t0x/org.openhab.binding.somfytahoma-2.4.0-SNAPSHOT.jar?dl=1

Fixes:

when multiple events with position change (DeviceStateChangedEvent) got in one event, only the first one (oldest) was propagated to the binding
refreshing all states is now event based - it starts when event RefreshAllDevicesStatesCompletedEvent occurs

the former version forced refreshing of states and immediately requested the states, which might not have been fully refreshed.

Thanks.
Ondrej