easiest way would be to add thermostat "sensor2 to youd node and adjust that to desired temperature. But since your node is sleeping you will have to request the set value when it wakes up.
Here is an example of how my power meter was getting last KWH from controller after power cut, I removed irrevelant code for clarity:
loop(){
if (!daySet) {
request(dayID, V_KWH);
wait(3333, C_SET, V_KWH);
}
if(!nightSet){
request(nightID, V_KWH);
wait(3333, C_SET, V_KWH);
}
}
void receive(const MyMessage &message) {
if(message.getCommand() == C_SET){
if (message.type == V_KWH) {
if(message.sensor == dayID){
dayCount = MeterRatio * message.getFloat();
dayCountOld = dayCount;
dayCountWatt =dayCount;
daySet = true;
}
else if (message.sensor == nightID){
nightCount = MeterRatio * message.getFloat();
nightCountOld = nightCount;
nightCountWatt = nightCount;
nightSet = true;
}
}
}
}
It was taking approx 2 seconds wits domoticz(2019 version) to reply to my requests.
You may run into errors with this method as your sleeping node won't send back ACK when you set new offset though.
Some controllers can disable requirement for ACK, i think.
More advanced way would be creating dummy thermostat to set new value(so you would have live and dummy thermostats) and using controller scripts to update the live thermostat on receipt of a temperature, you would have to wait after sending temperature or humidity.
@OldSurferDude jus request counter states from controller on each reset, worked fine with Domoticz...
or save in eeprom but increase location every write, on power up/reset search eeprom for largest value stored and carry on from that location, one long integer will fit 256 times in atmega328(p) eeprom, is that long enough for you ?
@bgunnarb I like @eiten 's solution for you.
Personally, I am not a fan of using cloud/public brokers. Thus I am curious about your system and there is something about it from which I can learn. I would like to understand why you cannot deploy your own mosquitto broker.
I see your set up as 3 sensor groups defined by the channel used
#define MY_RF24_CHANNEL ChannelOfSensorGroup
Each sensor group has some number of sensors and one MQTT GW on ESP8266. On the MQTT side, do you distinguish between gateways by using a different host name?
Something like:
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway-nOf3-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway-nOf3-in"
#define MY_MQTT_CLIENT_ID "mysensors-nOf3"
#define MY_HOSTNAME "ESP8266_MQTT_GW_nOf3"
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68
#define MY_CONTROLLER_URL_ADDRESS "test.mosquitto.org"
#define MY_PORT 1883
I must assume your controller (aka Home Assistant) discriminates between through which gateway the data is to flow by way of the different topic names.
If my "something like" is correct, then changing brokers is changing the IPaddress/URL in your gateways and in your controller (though if the controller is Home Assistant, it may be a bother because the device-id's may change which will make a mess of all the work you've done in HA. This is why I like @eiten 's solution.)
I hope it's all working for you again.
OSD
@OldSurferDude well, the ESP8266 is limited to 4 TCP clients in arduino IDE. This can't be really increased. I did som experiments and you can set it up to 15, but after the 5th client on my web server, I got a freeze.
Maybe you got something wrong. #define MY_GATEWAY_MAX_CLIENTS 2 defines how many controllers (eg Home Assistant) can connect to the gateway, not how many sensors/MySensors devices.
And yes, you can have multiple TCP gateways in HomeAssistant. I got an NRF24, an RFM95 long range and a RFM95 short range gateway (all based on ESP32) on the same Home Assistant.
Regards, Edi
