Hi Peter,
Yes, this was my mistake:
the error could imply that you copied the root-sonoff.py file in switch\sonoff.py folder also which is wrong!
fixing this and restarting HA, and switches appear on my dashboard.
Thank you very much.
Hi Peter,
Yes, this was my mistake:
the error could imply that you copied the root-sonoff.py file in switch\sonoff.py folder also which is wrong!
fixing this and restarting HA, and switches appear on my dashboard.
Thank you very much.
@peterbuga Thank you for this! I decided not to use Home Assistant because it was missing the ewelink integration and the community seemed a bit toxic to anyone suggesting adding it. Thanks to you I’ll be installing Home Assistant.
I have many sonoff basics and two 4 gang switches.
Now that I can use Home Assistant with what I already have, I now have a reason to do the Tasmota sonoff sensor project I’ve been putting off.
Unless your primary use case is voice integration instead of pulling out your phone or going to your computer to control anything.
My main turnoff to using Home Assistant was the toxic community. The point of home automation is ease of use not local control. Just because your focus is making everything local (a good and reasonable use) does not mean that is everyone’s focus. Please try encouraging development and integration it will help ensure the community becomes more robust and help Home Assistant remain viable with so many other options out there.
Have you read this?
If, after reading that, you don’t understand distaste for the cloud, then maybe home assistant is not the solution for you. Your focus may include some faceless company gathering and owning your data, but such approach is not generally home assistant’s focus. Its a free world, if you disagree, that is fine. HA is not a ‘product’ that requires ‘sales’. It is a community of developers and users.
As for toxicity, I suggest that, given the manifesto i have pointed to, coming here and claiming that resistance to adding cloud based components is toxic is the real toxicity.
My whole house is filled with Amazon Echos for voice control, obviously something that requires the cloud. However, should the internet go down, having local control using your phone to control as many of your devices as possible I would see as an advantage, would you not?
Relying too much on cloud devices makes this sort of control unachievable. 95%+ of my devices are set up with local control, so when my ISP goes down, which it does semi-regularly, almost all my automatons and lights/switches work as normal. Again, I see this as an advantage.
I just follow the philosophy of the HA founders when they state, “Your system should run at home, not in the cloud”. Everyone can, of course, choose how they wish to implement their own system
Hi
Very excited about this and love to try it with my sonoff basic
I am using hassbian and can not find the custom components folder. Pls can you explain where and how I create a custom folder
@Vaughanza according to documentation https://www.home-assistant.io/docs/installation/hassbian/installation/ should be here
/home/homeassistant/.homeassistant/custom_components
create the folder if it doesn’t exists and proceed with the instructions.
i’m sorry to say this but this problem it’s outside the scope of this thread and I’m highly confident this question has already been answered thoroughly already. search icon from topbar + google are your friends
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
@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)