Ok, that’s too bad. Shelley seems to have some interesting products at a competitive price that would be great for a smart home.
But thanks for the information.
Perhaps use a virtual device for each relay?
Yes, something like that. But the Shelly2 also had the measure_power capability which is one capability for both relays. I’m would not know how to do this without it getting to complicated. Perhaps 3 devices, one for the measure_power and two for the individual relays. Does not feel good though.
For the Sonoff Dual, which has 2 relays, I create just one device that has two onoff capabilities (onoff.1 and onoff.2). From what I understand, you create two devices (one for each relay)?
Never mind, you also create just one. In that case, if someone wants to be able to address a relay as if it’s a separate device, creating a virtual device seems to make sense. Perhaps, although I’ve never looked at it, you could share the measure_power capability between those two virtual devices.
I’m afraid sharing the measure_power would mean both virtual devices having to poll the actual device causing excessive traffic to the device. This dilemma made me choose for using two custom onoff capabilities with one device. But I’ll think it over some more.
If you have a trigger flow (“measured power has changed”), you would set the measure_power capability of both virtual devices to that value. I don’t think there’s any polling involved (fwiw, I’m talking about the Virtual Devices app and v1.5, don’t know if things are different on v2).
The current driver polls the Shelly2 device at a specified frequency which reads out the current usage and upstates the measure_power capability. To my understanding splitting the onoff capability over two separate devices would create two instances of the driver and thus poll the Shelly2 twice as well.
I think that we might be talking langs elkaar heen 
From what I understand, the current app creates one device for a Shelly2, and that device has two (custom) onoff capabilities, and also one measure_power capability.
Because of those custom onoff caps, it’s not possible to use voice commands to switch the relays.
That problem can, from what I know, be solved (by the user, not by you) by creating two virtual devices (class “light”, capabilities “onoff” and “measure_power”).
Those virtual devices, created with the Virtual Devices app, can have their capabilities set in flows, by triggering on “a relay has changed state” (I assume that your app provides a similar trigger?) and changing the state of the virtual device, and also vice versa, where a change of the virtual device switches one of the Shelly relays (again, this would require action cards in your app).
As for measure_power, you would do something similar, but only one way: trigger on a change of the measured power (and again, this would require your app to provide a trigger for that) and setting the virtual devices capabilities.
If you do consider creating two devices for one Shelly2, you could consider handling all communications from driver.js instead of device.js. I do something similar for the Sonoff app: instead of creating a new MQTT connection for each device, I create a connection for each broker, and let the driver find the correct device to pass the incoming data to.
Ah right, thanx for the clear explanation.
@LinaN, the method mentioned by Robert above is indeed a way to get the voice commands to work with the Shelly2 devices. It does require an extra app called Virtual Devices and some flows that keep the virtual devices and the two Shelly2 relays in sync.
That was a creative work-around, it works. 
The virtual device is classified as a light and is responding to voice commands as it should.
Thank you @robertklep
@Phuturist I know you said it probably won’t happen, but I secretly wish for a future upgrade of the app where it’s possible to classify the device and address each relay directly.
Perhaps someone in the community might be willing to assist in developing these features…? 
Thank you for all your help!
Hello,
Some progress in the investigation of the status of opening/close in percentage?
Not much, you can follow it here: windowcoverings_set capability is invalid · Issue #24 · athombv/homey-apps-sdk-issues · GitHub
Hello!
Yesterday update homey to version 2.0, everything seemed normal but the timer in the flows has stopped working, only opens or closes the shutter at 0 or 100%, does not respect the allotted time.
I imagine that it will be a problem of the homey itself. There are chances that the version with percentage opening will work in homey 2.0?
I can’t image that its related to the Homey version but there is no way for me to test it. Have you recently upgraded the firmware of your Shelly2? I’m not on 2.x and don’t have a Shelly 2. I could create a debug version on GitHub which you can run from the command line to see what is going on. Are you comfortable with this?
Don’t update shelly firmware, it’s the same last few weeks, no problem whit CLI.
Waiting for your new version.
Run this from command line (athom app run): GitHub - jghaanstra/cloud.shelly: Homey app to control Shelly Cloud devices
Let me know what the output on the console says when you try to set the blinds with a specific duration.
1 Like
This is the log that i get (2 roller shutters in the flow):
changing roller shutter with duration: undefined
changing roller shutter with duration: undefined
{ state: ‘open’,
power: 253.39,
is_valid: true,
safety_switch: false,
stop_reason: ‘normal’,
last_direction: ‘open’,
current_pos: 0,
calibrating: false,
positioning: true }
{ state: ‘open’,
power: 179.57,
is_valid: true,
safety_switch: false,
stop_reason: ‘normal’,
last_direction: ‘open’,
current_pos: 0,
calibrating: false,
positioning: true }
The cards are setting whit 13 seconds.
When i run the command get some errors:
{ state: ‘stop’,
power: 1.14,
is_valid: true,
safety_switch: false,
stop_reason: ‘normal’,
last_direction: ‘close’,
current_pos: 0,
calibrating: false,
positioning: true }
{ state: ‘stop’,
power: 0,
is_valid: true,
safety_switch: false,
stop_reason: ‘normal’,
last_direction: ‘close’,
current_pos: 0,
calibrating: false,
positioning: true }
(node:23320) UnhandledPromiseRejectionWarning: Error: invalid_capability
at Object.JSON.parse (/opt/homey-client/system/helpers/jsonfns.js:1:1190)
at JSON.parse ()
at jsonToObject (/opt/homey-client/system/helpers/jsonfns.js:1:1083)
at function.e.data.map.e (/opt/homey-client/system/manager/ManagerApps/bootstrap/sdk/v2/lib/HomeyClient.js:1:1379)
at Array.map ()
at HomeyClient._onMessage (/opt/homey-client/system/manager/ManagerApps/bootstrap/sdk/v2/lib/HomeyClient.js:1:1372)
at emitTwo (events.js:126:13)
at process.emit (events.js:214:7)
at emit (internal/child_process.js:762:12)
at _combinedTickCallback (internal/process/next_tick.js:142:11)
(node:23320) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:23320) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:23320) UnhandledPromiseRejectionWarning: Error: invalid_capability
at Object.JSON.parse (/opt/homey-client/system/helpers/jsonfns.js:1:1190)
at JSON.parse ()
at jsonToObject (/opt/homey-client/system/helpers/jsonfns.js:1:1083)
at function.e.data.map.e (/opt/homey-client/system/manager/ManagerApps/bootstrap/sdk/v2/lib/HomeyClient.js:1:1379)
at Array.map ()
at HomeyClient._onMessage (/opt/homey-client/system/manager/ManagerApps/bootstrap/sdk/v2/lib/HomeyClient.js:1:1372)
at emitTwo (events.js:126:13)
at process.emit (events.js:214:7)
at emit (internal/child_process.js:762:12)
at _combinedTickCallback (internal/process/next_tick.js:142:11)
(node:23320) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
Thanks for your help.
Strange, are you sure you have entered the duration as a number in the action card? You might try adding the card again. Perhaps something changed during the firmware upgrade.
I have also updated the Github repo with extra debug logging. Could you try again and let me know the outcome.
[EDIT] once this issue is resolved I would like to as you to test the functionality of setting the blinds in percentage on firmware 2.x. Athom just closed my bug report about this capability because appearantly they do not support issues on 1.5.x anymore. So I need to know if this issue is also present on firmware 2.x. I will need to upload another version on github and you would have to repair your shelly2 as roller shutter while running the app from the command line. Would you help me out with this?
Yes, not touched the flow and work perfect, after homey update the blinds open to 100%, ignoring the time of action card. Try to remake a new flow and the same result.
Test the new app:
changing roller shutter with duration: undefined
{ direction: ‘close’,
device:
Shelly2RollerShutterDevice {
domain: null,
_events:
{ __capability: [Function: bound __onCapability],
__renamed: [Function: bound __onRenamed],
__settings: [Function: bound __onSettings],
__added: [Function: bound __onAdded],
__deleted: [Function: bound __onDeleted],
__init: [Function: bound __onInit],
__log: [Function: bound ],
__error: [Function: bound ],
__debug: [Function: bound ] },
_eventsCount: 9,
_maxListeners: undefined,
pollingInterval:
Timeout {
_called: true,
_idleTimeout: 5000,
_idlePrev: [Object],
_idleNext: [Object],
_idleStart: 137580,
_onTimeout: [Function],
_timerArgs: undefined,
_repeat: 5000,
_destroyed: false,
[Symbol(asyncId)]: 95,
[Symbol(triggerAsyncId)]: 90 },
[Symbol()]:
Shelly2RollerShutterDriver {
domain: null,
_events: [Object],
_eventsCount: 9,
_maxListeners: undefined,
id: ‘shelly2-rollershutter’,
[Symbol()]: [Object],
[Symbol()]: [Object],
[Symbol()]: [Array],
[Symbol()]: [Object],
[Symbol()]: true,
[Symbol()]: [Array] },
[Symbol()]: { emit: [Function: emit] },
[Symbol()]: true,
[Symbol()]: ,
[Symbol()]: { id: ‘CE50E355A57A’ },
[Symbol()]: { windowcoverings_state: ‘idle’, measure_power: 0 },
[Symbol()]: true,
[Symbol()]: ‘Persiana Grande’,
[Symbol()]: ‘windowcoverings’,
[Symbol()]: [ ‘windowcoverings_state’, ‘measure_power’ ],
[Symbol()]:
{ address: ‘192.168.1.162’,
username: ‘XXXXX’,
password: ‘XXXXX’,
polling: 5 },
[Symbol()]: {},
[Symbol()]: ‘18a538b7-69db-4dc7-a60e-0c1742447d84’,
[Symbol()]:
{ windowcoverings_state: [Function: bound onCapabilityWindowcoveringsState] },
[Symbol()]: false } }
But now i can see that homey knows the position:
current_pos: 29,
And is the same as shelly app position.
Of course i help you.
It seems that the action card is not passing on the duration argument from the action card to the function that handles the change in position for that specified duration. As this used to work just fine on 1.5.x I’m not sure if I can actually fix this within my app. To me it seems as a bug in Homey itself. Could you post a screenshot from the Homey app where you configure this action card, perhaps that tells me what might be wrong.
About the current position. I’m already updating the current position from the Shelly device to Homey but there is an issue with adding this capability to the device. That’s exactly why I can use your help testing this further once I have tackled the above issue.
