@krash to quickly answer your main question, in one way or another, anything that can be done with the mobile app can also be done by this component … the only problem is how much work needs to be done to “translate” the mobile API to HA integration (i’m saying this because i have the feeling that the API was created by countless minds, the rules keep changing from section to section like it’s the result of some -code)
your request is somehow particular and i would appreciate if we could continue this discussion in a github issue because i can quickly think of a few things that can easily extend the logic for this feature, like how do you represent the timers? do you turn off all per device or just a specific one? and so on.
in the same time i can also say that i will not add this option anytime soon so it’s up to you if you want to continue with this or not. right now i’m dedicated to integrate all the devices people throw at me and add extra features later (hope you understand)
Totally understandable.
I will start a github issue to propose my thoughts just for the good house-keeping of the project.
Just to clear things up, i was talking about Schedules and not Timers (was just confused with the tasmota terminology) and i am referring to the master switch of each schedule as a first implementation step.
Like in my case, for my 4 irrigation zones, i can set 4 On and 4 Off schedules (8 in total). I would like to be able to control their master switches remotely from HA (so i can do it automatically depending on weather data). If i had that remote control access, i could also set different sets of on/off switches and enable/disable the different sets depending on how long i want it to water the garden.
I should add here, in case someone is interested in an irrigation project, that i just installed a sonoff 4ch to controll my home irrigation using this wonderful code by @klogg but my needs on this project were different and it depends on hassio to run the on/off and not on internal eWeLink scheduling. Klogg’s code is set up with tasmota devices but it’s easily usable with @peterbuga’s component too. (gimme a shoutout for help, i just went through it)
Good to hear that it is possible and that one day it might be implemented.
Thanks again.
Github Issue opened, hope i did everything correctly
hey peter i want to use this component for cover integration in home assistant. i’ve just created a cover template in home assistant all is good but when i expose it in google home and i ask to google home to close or open cover, google says me ok i will close/open twio devices but nothing happen. Why?
does the cover works in HA by itself? meaning can you toggle it successfully without any templating/automation/etc? if not, then most likely it’s not supported yet. please go to project’s page and read carefully the debug section and how (to open a new issue for it and) to provide the useful data i need in order to complete the integration
if you can use the cover in HA just fine, than it’s probably another type of problem outside the scope of this thread and it’ll be better (reached) if you open another thread about it
Ok yes in home assistant covers go well I have not automation i have only open close and stop cover. They are simply. I hope to solve it thank you for all
error from callback bound method Sonoff.on_message of custom_components.sonoff.Sonoff object at 0x69a63cd0 ‘NoneType’ object has no attribute ‘attributes’. How can I solvei think it will be something about component
Ok I will continue my request here for the Chacon devices. The appz for this device is different (play store: chacon home)… so no more eWeLink based …
I know you already did a huge work to integrate most of the sonoff devices … but maybe you can fork this project and work on the chacon conponent for HASS. I know you probably don’t have this device… if you are in europe, I can send one to you.
Well … because I already got 4 of these devices, they are older than shelly’s… In another hand I ordered a shelly 2.5 for my testing… I hope to received in a couple of days (2 batch order). In the worst case, I will have buy 3 other Shelly to swap my chacon devices.
For the Chacon’s devices… (popular here in west europe), there was an attempt to make a Jdoom module: https://www.jeedom.com/forum/viewtopic.php?t=23435
Not a lot of informations inside the first msg… but can be a hit.
To be honest, I am completly new in Home assistant… so it will take me a couple of days/weeks/months… to start to have a global view. But I already managed to install HASS and the eWeLink integration within 1h
this looks like a response to the ever growing list of devices that offer REST api too (it was about damn time!)
in the same time i think they might turn obsolete this component with a few firmware updates not sure if i’m happy or not yet
Thanks again for your hard work Peter. Yes, I am willing to test for you.
I was in fact looking at your code because HA complains:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 365, in _async_add_entity
await entity.async_update_ha_state()
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
self._async_write_ha_state()
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 248, in _async_write_ha_state
state = self.state
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 456, in state
return STATE_ON if self.is_on else STATE_OFF
File "/config/custom_components/sonoff/switch.py", line 75, in is_on
self._state = self.get_state()
File "/config/custom_components/sonoff/__init__.py", line 646, in get_state
return device['params']['switch'] == 'on' if device else False
KeyError: 'switch'
The B1 does not have a “switch” in its params array:
(i’m saying this because i have the feeling that the API was created by countless minds, the rules keep changing from section to section like it’s the result of some 
-code)
