My comments relate to using the iHosts eWeLink app. Probably will work with another Docker App.
1 Like
If you leave your internet disconnected and then remove the power from the device that is in the IF statement, once you restore the power to it you will find that that the scene will not function with the internet down.
Maybe in that instant that the device is offline, but then it will restore connection and the scene will run.
Would be best not to hijack the thread and confuse the OP with this theme - maybe open another topic if you like?
I’ve re- performed all the tests I carried out under the previous version of iHost eWeLink Cube and as you rightly say those functions actually do now work properly under the latest version for iHost, even when without internet the wi-fi device is powered down and powered up again- Sonoff must have listened to the comments on here and addressed the short coming (previously wi-fi devices needed to access eWeLink Cloud on power up to retrieve some of the devices parameters). It’s not a question of me hijacking OP but more of being interested in achieving systems that are more resilient to failures and recover from failures in a predictable reliable way- especially when the system is auto controlling something like a heating system. Thanks for pointing out your findings as it prompted me to re- test scenarios that caused me concerns.
1 Like
Your comments are noted but I think one of the problems is that Sonoff/ eWeLink are not the best communicators in the world. The result of something tested today under the current version of iHost eWeLink may yield a completely different result when the same test is carried out under a future version.
All cloud-based automation systems require a connection to a server. eWeLink is no exception. Note also that WiFi devices do not download any configuration data from the cloud, because there is no such data there. Once configured, they work with a given WiFi network. Automation (scenes) are something else. They are performed on a remote server. Without connectivity to the cloud, they will not be executed, which is obvious. In LAN mode, access to the remote server is not required for scenes created locally (e.g. on iHost) to be executed.
@ward As an aside, a WiFi device signalling a loss of connection to the cloud (LED flashing) does not mean it is impossible to work in LAN mode if it is enabled and the device in question supports it. This is sometimes confusing and I would suggest to the eWeLink/Sonoff team to distinguish between signalling loss of cloud connection and loss of WiFi connection.
1 Like
The new sonoff devices have been so simplified that they do not have a diode to indicate when the relay is turned on.
Really? Which have been simplified to such an extent?
MINIR4, MINIR4m, BASICR4
There is only a blue diode that lights up when connected to the cloud or flashes when there is no connection
I think that the Sonoff/ eWeLink team do need to be clearer about what features in the wifi devices are reliant on eWeLink Cloud. For eg I found by testing that under the previous ver of eWeLink for iHost that the loop timer in Sonoff Basic Switches would not operate in a scenario where the iHost lan is not connected to the internet, the power to the device is disconnected from it and then restored. They seem to have got the feature working now for that scenario in the latest ver of eWeLink for iHost. That is quite a important feature for my system designs that are not reliant on the internet/ their eWeLink Cloud using a basic switch to trigger a synchronisation scene to run after a power up condition to sync mains operated wifi switches as ‘slaves’ to their battery operated TRVZBs as ‘masters’
I think this is clear enough by now. I do not think that any action is needed. No cloud-based home automation system will work properly without an internet connection.
I don’t really understand the description of the situation and the linkage within the “master-slave” scenario you give. It is pretty confusing. It must be a highly complicated issue 
The ‘Master/ Slave’ scenario is one device commanding another eg TRVZB on ‘Heating’ status making another device (eg Basic WiFi Switch via a scene) turn on and turn off when ‘Keeping’. Problem is that TRVZB sends the command but there is no check that the target device has switched to the commanded ON or OFF condition. So in the systems that I design the TRVZBs are on all the time every day but the slave wifi devices are powered down during the non heating season. The system is designed so that when the external temperature drops to a pre defined value (sensed by a mechanical frost thermostat) the slave devices which are wifi switches are powered up so enabling the boiler to fire up the central heating system. Problem with a simple arrangement is that the conditions the switches power up in may not be the conditions that the status of the TRVZBs say they should be in. The solution is to use a single Sonoff Basic wi fi switch to initiate a start up sync process. The sync switch is set to power up in the ON condition and runs a loop timer to switch to OFF after a preset time. The change of state from ON to OFF starts a series of scenes that basically sets all TRVZBs to OFF and then to AUTO which causes the ‘slave’ wifi switches (one for each TRVZB) to be syncronised to the condition that it’s TRVZB master commands it to be in. Another benefit is that a press on the button on the start up sync basic wifi switch initiates a manual re- sync. Under the previous ver of iHost eWeLink the process would work fine when the internet was connected but not without the internet. This seems to have been resoved with the latest iHost eWeLink firmware update. It’s not an elegant way to achieve this solution but I aim to use standard hardware and the standard iHost eWeLink scenes. The design is make the system resilient without access to the internet and when emerging from the non- heating season or a power outage.
I now understand your concept of master/slave. Yet it does not correspond to reality in the sense of device dependencies.
When I still had iHost, there were no problems with scenes where the Zigbee device triggered an action with WiFi devices in LAN mode even when there was no connection to the cloud. I have no reason to believe that what you write about is impossible. Apparently it is, but it is surprising.
I use similar solutions with Sonoff WiFi devices in Home Assistant (ZHA add-on and automatic LAN/cloud mode operation). I have never observed anything similar. Maybe the eWeLink guys have an explanation?
As for the TRVZB measuring temperature, I wouldn’t rely too much on that. Firstly because the readings are sent relatively infrequently due to power consumption. Try using an external, standalone temperature sensor that works with higher resolution and more frequent reporting. In addition, you will avoid any distortion due to the location of the sensor.
Yes you are correct that the TRVZBs do not frequently broadcast their temperature-- it has to be a compromise. Yes there are a few instances where I have used separate temperature sensor/ thermostat and activated the radiator valves with thermo- electric actuators. I think Sonoff/ eWeLink need to improve the structure of their Scenes- the 1 IF Statement for each scene is a very limiting factor- it wouldn’t take too much to include AND and OR Statements.