Sonoff HT1x scheduler by temp

[Alferez]

I need to schedule an ignition task for an HT16 depending on the temperature.
I have reviewed the scheduler section and I see how to activate the selected hours and days, but I need it to only activate if the temperature of the ds18b20 is below 20 degrees for example, but if the temperature is 38 even if it is in that time period it will not activate

Is there an option to enter the temperature in the scheduler? Is it and I have not seen it?

Thank you

[icevoodoo]

This will be a nice feature. I need this also for heat radiators in winter or for AC. Also we need to can set a hysteresis value (ex: +- 0.5 degree). When the temp drops below target value (ex: 20 degree) -hysteresis value then relay on, and when the temp goes beyond target value +hysteresis value then relay off. This feature combined in schedule will be very useful (can replace with success a programmable thermostat).

[lobradov]

Why not use home automation software for that, or anything else that requires complex logic? Your rules can (and should) become even more complex and they can't all be implemented in firmware... What if, for example, heating stays on depending on your presence/location and time/day of the week (if temperature is less than threshold and you are within 100m of your house on workdays... ) In general, industry automation is very clearly split into 'logic' and 'sensors/actuators'... I think home setups should follow similar pattern for scale and robustness... Setting up (even remote) NodeRed is quite simple... //_

…

On Feb 22, 2018, at 08:53, icevoodoo ***@***.***> wrote: This will be a nice feature. I need this also for heat radiators in winter or for AC. Also we need to can set a hysteresis value (ex: +- 0.5 degree). When the temp drops below target value (ex: 20 degree) -hysteresis value then relay on, and when the temp goes beyond target value +hysteresis value then relay off. This feature combined in schedule will be very useful (can replace with success a programmable thermostat). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Alferez]

Of course if you use the management soft there is no problem, but in my case I need it for an isolated location, which when I have to reprogram I put the phone in tethering and that way I access the configuration.

It is a Boolean logic of 0 or 1 but with an exception case.

It is only activated at time 12 and deactivated at time 14 but as a condition that the ds18b20 registers a temperature lower than 20 C in the case of heat radiators or that the temperature is higher than 30 C in case of AC.

It's a feature that has the device in an original way and I think it's a shame to lose it.

I only propose it as a possible feature in a future version.

[icevoodoo]

I need this because I don't wanna use an RPI3 + node-red, and set directly from ESPURNA web interface.
Also I need that TH10 or TH16 to work autonomous. Do you think is fair enough :). And I guess is not so hard to implement this, and by the way the original firmware for SONOFF can do this already...

Maybe this is not an issue, is just an improvement, new features call it whatever you want...

[AlbertWeterings]

It is resenabel simple to set alarms on low and high temperatures with a ds18b20. I agree with @lobradov that building these kind of features in ESPURNA is going beyond what ESPURNA is build for, what is next switch something based on scheduled lux values? You can also think of having a Attiny to handle temperature measure and hysteresis and have it communicate with ESPURNA over a IO line.

[Alferez]

I do not think it is asking Espurna more than what was designed, I think Espurna gives a series of features that were not designed or impemented, but this feature was implemented and has been removed:

https://www.cnx-software.com/2016/11/18/getting-started-with-sonoff-th16-esp8266-relay-and-sensor-using-the-stock-firmware-and-ewelink-android- app /

Of course if I want it to work well I can use the original firmware, that does not prevent me from anyone, but I think that as a future feature it could be fantastic to recover the original feature..

[icevoodoo]

TO: AlbertWeterings

If I follow your logic, then why we have schedule implemented ? An yes you ca implement for other types of sensors but by making a smarter If ... Then condition. Ex.: IF [sensor (selectable from available)] followed by a selectable condition (=, >=, <=, <>), followed by target value THEN [relay_action (on, off or switch)].

It's not a big deal. I ask this mainly for SONOFF products, but I think it will be useful for others too. If you read what I have write previous in my post you will understand why is useful. I want to do this from ESPURNA web interface only for set it and forget it devices, and i don't need an RPI+node-red.

[AlbertWeterings]

@icevoodoo it is not difficult to implement, my logic is different ESPURNA is created to be used on a wide scale of hardware a big part of this hardware have no sensor inputs. So for the hardware not having sensor inputs it makes no sense to have sensor related settings in the scheduler. (I'm ready for your argument then only enable these settings in specific hardware by configuration ;-) )

The original firmware for Sonoff HT16 also doesn't have these options in it. These options are in the eWelink App, behind this App hides the intelligence on a server that send the preferred settings to the HT16 and the HT16 will act on it. By that way the firmware stay's small and reliable. I fully agree with @lobradov there are better places to put complex intelligence.

For example if you put intelligence on a central place you can control actuators with complex intelligence based on measurements of multiple sensors and schedulers instead of being limited to the one sensor connected to the same TH16 controlling the actuator.

[icevoodoo]

If it is so hard or have no sense leave it like it is. This is progress...
10x for all watching this thread, I will stop here.

[Vadonat]

hi.in the original firmware is have the thermo control.not the app.when the th16 offline the switch uses the own memory.i tryed it.

[xoseperez]

My original idea before the current scheduler, a contribution by Stefano Cotterli (https://bitbucket.org/faina09/), was to have several inputs including time (of course), sensor data or external data via MQTT. Any of those inputs and some basic operators (==, !=, >, <, >=, <=) could trigger a change in any given relay. Sure, you can also think of different outputs too (colors, actuators,...) but my original idea was to target only relays.

I admit it was never a priority because - as @lobradov says - you can (and you should if possible) use an external automation system for that and it will give you much more options than an ESPurna device alone. Me myself I use Node-RED for that. When Stefano issued a PR with his scheduler it was great since that covered part of the functionality I had in mind and it should not be hard to implement the other inputs. But I reckon that if it were not for him the scheduler wouldn't exist, yet.

Same for other features, like MQTT groups, for instance. I feel them like unnecessary on 99% of the use cases, but it was cheap to implement... At the end it is a matter of how much time you have to work on this and, to be honest, when talking about new features, I prioritize those I will use.

[icevoodoo]

Al least we have a proper answer. So it's a matter of time, money, interest, opportunity, etc. Please don't loose from your site of view this for the future, and take in consideration this scenario (for Sonoff TH10 and TH16 and maybe for other devices):

There are people who don't need to centralize (for lower cost) some dumb task like maintaining temperature and humidity in a bathroom, kitchen, basement, etc. They want to set the thresholds and the device do the job (action a fan, ac, thermostat, light, etc...). If we have centralized through RPI+node-red when this die, or freeze all the slave devices stop functioning or worse they continue to function...

So we will wait maybe in the future will have this...

10x!

[jkroby]

Hi, some update about this future?
I need the same, thermostat, i have the same problem, i use sonoff for control heating home system (primary) so i can't have a central controller it have to be more robust, every device must can work alone.
The price for me is not a very problem but it require too components that can stop and so all stops! It is non good :)
Roberto.

[klbsss]

Hi, some update about this future?
in dev branch error:
.pio/build/wemos-d1mini-relayshield/src/espurna.ino.cpp.o: In function ArduinoJson::Internals::JsonParser<ArduinoJson::Internals::CharPointerTraits<char const>::Reader, ArduinoJson::Internals::DynamicJsonBufferBase<ArduinoJson::Internals::DefaultAllocator>&>::parseObject()': /home/stas/espurna/dev/code/.pio/libdeps/wemos-d1mini-relayshield/ArduinoJson_ID64/src/ArduinoJson/Deserialization/JsonParserImpl.hpp:116: undefined reference to magnitudeTopic(unsigned char)'
.pio/build/wemos-d1mini-relayshield/src/espurna.ino.cpp.o:(.text.Z22thermostatMQTTCallbackjPKcS0$part$775+0x83): undefined reference to magnitudeTopic(unsigned char)' .pio/build/wemos-d1mini-relayshield/src/espurna.ino.cpp.o:(.text._Z22thermostatMQTTCallbackjPKcS0_$part$775+0x9e): undefined reference to magnitudeTopic(unsigned char)'

[mcspr]

@klbsss If THERMOSTAT_SUPPORT is enabled, you need to specify at least one sensor like DHT_SUPPORT or BMX280_SUPPORT.

Build is failing because it can't find the magnitudeTopic(unsigned char) definition, which is not there since SENSOR_SUPPORT is still set to 0 and not 1. Maybe we can implicitly enable SENSOR_SUPPORT to avoid compilation error. Magnitude list is a per-sensor property though, so idk how to "know" which magnitude is available or which one is not at build time.

[klbsss]

Спасибо!
successful compilation, I'm going to test, thanks a lot

[buitre-buitaker]

Спасибо!
successful compilation, I'm going to test, thanks a lot

What about the tests?