Idle ?

[IanAdd]

If the target temperature is below the current temperature shouldn't the action payload be "idle" rather than "heating" ?

[fashberg]

Hey @IanAdd !

If you have the Hardware-Mod then the WiFi-Module knows the real state of the heating relay - then, and only then, action will change to 'idle' if the ralay is of. Without Hardware-Modification the WiFi Module can't rellay know the state of the heating.

klausahrenberg/WThermostatBeca#17 (comment)

The only thing would be to simulate difference between targetTemp and measuredTemp.

The Thermostat seems to has the following hysteresis implemented.

• if currentTemp <= targetTemp - 0.5 then switch on
• if currentTemp > targetTemp + 0.5 then switch off

Maybe i can simulate

Kind Regards

[IanAdd]

Hi
Thanks for responding.
My thermostat is in a cupboard in a different room to the heated floor (a bathroom) so I have to ignore the main temp sensor and use the floor sensor to determine if it should heat or not I guess that there is not much you can do unless you add a user option to say which sensor should be the controlling one.
Fortunately the target temperature I set is always above the 'room' temp sensor when I want to heat. I set the target to a very low temp when I don't want it to heat.
Also my heating element is not powerful enough to ever reach my target temperature so I do not need to regulate on/off on reaching target.

[IATkachenko]

@fashberg, hello.

Simulating is not good idea:

1. Deadzone (1 by default) may be changed by user, up to 5;
2. Thermostat may be in any mode if temperature in range [target - deadzone; target], because it should heat if low end was initial point and be idle if it starts from high end.

By the way, SmartLife application shows current heater status (on/off), so this information transfers to WiFi module for stock firmware. May we got it for idle state detection?

P.s. I may help with tests/debug if it needed.

[fashberg]

Hey @IanAdd and @IATkachenko

Version https://github.com/fashberg/WThermostatBeca/releases/tag/v1.16-fas has now "RelayStateCalculation".
Feedback appreciated.

@IATkachenko : I think SmartLive shows device-state on/off, but not relay state!
If temperature changes and relay turns on there is only the information coming from MCU 'temperature changed' - so we must calculate based upon DeadZone.

Kind Regards
Folke

[IATkachenko]

@fashberg, unfortunately I flashed WThermostatBeca to my BHT-3000 after 30 minutes of test with SmartLife application and Home Assistant integration and have no screenshots, but thermostat interface have on/off button, mode buttons, data from internal and external sensors, temperature selector and relay status icon (that looks like fire) that shows/disappear based on relay status (it may be simulation too, but application have such icon and it is not on/off icon).

And about "RelayStateCalculation".
Looks like you have logic mistake in https://github.com/fashberg/WThermostatBeca

WThermostatBeca/WThermostat/WBecaDevice.h

Line 1936 in 50952d8

} else if ((actual < oldActualTemperature || target>oldTargetTemperature) && actual <= (target - dz)){

:

old_target = 30, target = 30, dz = 1, actual = 25, old_actual = 24.5 => relay should be in HEATING state.
but (25 < 24.5 || 30 > 30 ) && 25 <= (30 - 1) => (false || false) && true => false && true => false => State is not heating.

Also I'm not sure about deadzone: is thermostat switch relay off at (target - dz)? For my observation it switch relay off just at target: for now I have target=30.5, actual 29.5 and relay is on. Relay stay ON at actual 30.0 and switch off at actual == target. Then is stay off till actual > (target - dz) and ONs again at actual = target - dz.

Looks like condition should be:

else if ((actual > oldActualTemperature && actual < target ) || ( target > oldTargetTemperature && actual <= (target - dz) ) )

relay is not turning ON if we increase target temperature in deadzone, but it stay ON if target > actual > target - dz for full processing cycle (see my observation above).

[fashberg]

Hey @IATkachenko !

looks better - applied to 1.17-fas
Thank you for the fix and

Kind Regards
Folke

[IATkachenko]

@fashberg, I was not completely right with my suggestions, sorry :(

Your original condition is correct. I was not familiar with message publishing algorithm: you are catching moment of start heating and change state just at this time. All other temperature changes is not require publishing new (or same) state.
My mistake was in assumption that we need set state at every temperature changes and I missed out that state is keeps during iterations. As a result first temperature increasing occurs with idle state.

My bad, sorry for confusing, algorithm in 1.16 was correct.

[fashberg]

Hey @IATkachenko ,

OK, there a third version.
We can ignore if temperature increases or decreases. It's just and simple:

• as soon as actual>= target ==> Switch Off
• as soon as actual <= (target - dz) ==> Switch On

I've fixed another Bug in 1.17 that not all incoming updates started recalculation of the Heating State.

You can test 1.18.beta1-fas - here attached in a ZIP or compile with gitpod or pull current master
wthermostat-1.18.beta1-fas.bin.zip

			if (actual>=target){
				network->log()->notice(F("RelaySimulation: State OFF"));
				this->state->setString(STATE_OFF);
				updateModeAndAction();
			} else if ((actual != oldActualTemperature || target!=oldTargetTemperature) && actual <= (target - dz)){
				this->state->setString(STATE_HEATING);
				network->log()->notice(F("RelaySimulation: State HEATING"));
				updateModeAndAction();
			} else {
				network->log()->notice(F("RelaySimulation: NOOP"));
			}

[fashberg]

fixed in 274a38e