Ok thanks for the advice. Super excited to get the switches working . Thanks for work you done
@peterbuga this is awesome. Thanks very much. Now I get a million IFTTT applets out of my processes!
I installed it and it worked first time 
Just FYI, I have a few Sonoff DUALs. They report 4 channels rather than 2. The entities ending _3 and _4 seem to do nothing. _1 and _2 work exactly as expected 
1 Like
@Michaelrch glad you had it working ! you could try the websocket branch from the project, there’s an overall code improvement and the updates/states of the switches are done over websocket instead of polling meaning that if you change the switch from eWeLink app it also shows up almost instantly in HA - it will also try to detect how many switches your device has (for now just ignore the _3 & _4).
@forums2012 reported that this code re-write works pretty good (with a small hiccup) but the Xmass period kicked in and I didn’t had time (or mood) to move everything into the main branch.
Thanks very much. I have installed the websocket branch and it seems to be working fine. I noticed that the devices are renamed without the “sonoff_” prefix which makes sense as it reduces clutter in the config. Some find/replace later and everything is looking fine.
Also, the dev tools no longer see any switches suffixed _3 or _4 for the DUAL sonoffs so that is working well!
When you say that HA can now track the status of a switch if they are changed from the ewelink app more promptly, I am wondering if that assumes that the app is using a second ewelink login because HA/your code is using the first, right?
Thanks again. This has allowed me to remove tons of complexity from how I use my Sonoffs and made everything more responsive.
a bit tricky to explain how the eWeLink app works but if you plan to use only one account (no shared devices to a second account) + websocket branch the quick explanation would be like this: *every time the sonoff component is started (usually upon HA [re]boot) you will 100% be logged out of eWeLink app from mobile and this generates a login-token. this login-token is used to do a 2nd login for the websocket part, as long as the sonoff-websocket stays logged in inside HA (meaning your internet connection doesn’t drop and alike) you can login again in the eWeLink app and in this moment app and HA component can work in the same time. if the HA sonoff websocket drops for any reason, a re-login process will be triggered and process from the *beginning starts all over again.
it’s a bit complicated because eWeLink API doesn’t allow same login from multiple places in the same time…
(try to read this a few times if you have trouble understanding it 
if not, just accept the magic as it is 
)
Thanks, I think I follow. It works and that’s good enough for me!
Something a bit odd I’ve noticed. I am trying to record the state of a switch into a hass-variables variable. hass-variables is a handy add-on that’s pretty reliable, as far as I’ve used it anyway.
When I try to set a variable to
{“variable”:“light_state”,“value_template”:“{{states.switch.10005d532d.state}}”}
in dev tools, the call fails. I have checked that the set_variable call and syntax is working ok by using
{“variable”:“light_state”,“value_template”:“{{states.light.tv_room.state}}”}
and that evaluates fine.
The last error in the log is as follows
voluptuous.error.MultipleInvalid: invalid template (TemplateSyntaxError: expected token ‘end of print statement’, got ‘d532d’) for dictionary value @ data[‘value_template’]
Just checking, does this look like it could be related to the sonoff code, or do you think it’s more likely to be the variables code?
Thanks
PS I took my script syntax from here
Where the author is using the variable.set_variable service to set a variable to a switch state (it’s a sonoff but a tasmota-flashed one in his case because he doesn’t have your code 
)
PPS actually, the example didn’t set a variable to a switch state! My bad. I have looked around a bit further and found a reference to something similar elsewhere. So now I am going to try using getting a Boolean by evaluating to
{“variable”:“light_state”,“value_template”:“{{ is_state(‘switch.10005d532d’, ‘off’) }}”}
PPPS FWIW, this is fixed. Nothing to do with your code! This code to get the state into a Boolean
- service: variable.set_variable
data:
variable: light_state
value_template: "{{is_state('switch.10005d532d', 'on') }}"
Then this to reset the switch after my operation
- service_template: >
{% if is_state ( "variable.light_state","True" )%}
switch.turn_on
{% else %}
switch.turn_off
{% endif %}
entity_id:
- switch.10005d532d
Now I know! Sorry to bother you with this.
Does hass-variables work in general? Because something was broken and the author released a fix for 0.84+ (check the hass-variables github - I’m on mobile)
Yes, although not how I expected. FYI I updated by earlier post with the solution as, in the end, it was not relevant to his code AFAICS and I didn’t want to spam his thread.
Yes, it is worth noting that the three fan speed switches are cumulative (1 needs to be on for 2 to work etc).
I am currently trying to use scripts to fix this (done in HA) but struggling to get scripts exposed in Google Assistant.
I haven’t played with the fan settings too much, but I use Alexa so id just make a couple of different groups using that app. 1 for low and medium and 1 for low medium and high.
Sorry I can’t share the script output, I can seem to get it to run.
Thanks, I got it going. Scripts came across but I needed to go to home automation to add them to a room now “activate fan medium” etc. works fine.
Hello there. Thanks @peterbuga for this super useful component! I have one question related to you warning advise on GitHub: “WARNING: completely deactivate the sonoff component from HA while doing a firmware update.”
You mean during the fw update of the sonoff devices?
Thanks
@CarloN that’s exactly what it says! but in the same time, what do you think it was referring to? i’ll be more than glad to update the warning message with a proper meaning (IMO i was under the impression the message was clear enough)
That’s what I understood.
To avoid trouble, I comment the sonoff section of my config file.
Restart HASSIO.
Update my Sonoff switches
Uncomment the sonoff section of my config file.
Restart HASSIO.
Seems to go fine.
The danger to avoid is HASSIO could/will login to ewelink (which it is trying to do all the time) right when the Ewelink app is trying to complete the update process, therefore disrupting the connection to the device is even breaking the firmware update process.
@peterbuga thanks for your clarification. Your warning advice is absolutely clear and is enough! My question because I’m trying to figure out how (technically speaking) if I updat the devices fw via eWelink app and the component on HA is in dialogue with the eWelink server this corrupt the fw update, maybe for the same reason because you can’t connect two smartphone at the same time, is an eWelink limit.
A million thanks @peterbuga
That’s a very valuable component to use the main switch functionality of sonoffs.
Glad to say it worked like a charm, already tested it on a sonoff basic.
It also imported a sonoff inching i got in my account, but it’s remotely placed so i cant test if it’s working, but will when im over there and report back.
Thanks again!
That’s a good point @krash
@peterbuga, is it possible to get control of other features of the switch like turning on and off inching settings, or the device LED?
Is not super important. It would just be handy for some applications. Eg I have my DUALs running some window blinds. A short pulse would be best for opening or closing the slats (using inching) while to raise or lower blinds takes 30 seconds. So it would be handy to be able to do both modes programmatically.
there are already opened issues on the github project to add various new devices/sensors to this component, i’m really excited to add them all! due to this holidays period and because + kinda traveled i halted the development for now. one really big problem while developing this specific component is that i cannot test what i’m writing because i don’t have the devices itself 
therefore it’s a bit blind coding from me + testing help from the person who requests a specific device/feature.
please open an issue with sonoff-debug.py output and i’ll try to add the inching options too for a real inching device. In the case of Sonoff Dual i think you can just send ON/OFF commands from HA, if this doesn’t work i might add be able to add a service call to (hopefully) simulate the inching [with a variable time configuration] on normal non-inching devices, how does this sound ?
Thanks @peterbuga
I’m extra impressed that you go his far without even having a Sonoff! Extra kudos. DM and I’m happy to PayPal you the cost of a new DUAL or Basic!
Re the inching, it’s actually a mode that you put the device in. It came in a recent firmware update. I don’t have a dedicated inching device like @krash
In the device settings, say for a Basic, you specify the mode (inching on/off) then you specify the inching time in milliseconds. Then when you command the device on, it goes on and then off automatically after the interval, I think as one command that the Sonoff gets.
I have tried sending an On quickly followed by an Off but the lag makes it an unreliable process. I think the inching mode takes out the lag because the Sonoff does the on/off interval locally.
So would it be useful to do the required fiddling with the settings and sending the command to the device from the app? Would your debug capture see everything relevant even if it was going from the Ewelink app?