disable/cancel smartSleep while sleep countdown is running

[tmandel]

@mfalkvidd

I made some more investigation and sortet my code a little bit. The problem still exists.
FHEM sends the next commant to my node when the node sends I_PRE_SLEEP_NOTIFICATION.
But in this situation the smartSleep counter is already counting down.
The node receives the value of 1 but goes to sleep right after that. After Next wakeup the node runs through the loop and stays awake.

In my opinion there should be 2 solutions for that problem

1. FHEM sends new values after I_POST_SLEEP_NOTIFICATION
2. in mysensors there is a method to cancel smartSleep countdown

//	###################   Debugging   #####################
#define MY_DEBUG
#define SER_DEBUG
#define MY_RF24_PA_LEVEL 					RF24_PA_LOW
#define MY_RADIO_RF24
#define MY_RF24_CHANNEL 					96
#define MY_TRANSPORT_WAIT_READY_MS 			(5000ul)
#define MY_TRANSPORT_SANITY_CHECK

#define MY_NODE_ID 							110
#define MY_PARENT_NODE_ID 					0		//without this passive node broadcasts everything to parent 255 (dont know what happens, if 2 repeater receive this at the same time)
// #define MY_PARENT_NODE_IS_STATIC
// #define MY_PASSIVE_NODE


// ###################   Node Spezifisch   #####################
#define SKETCH_VER            				"1.0-002"        			// Sketch version
#define SKETCH_NAME           				"LEDSwitch"   		// Optional child sensor name

#define SLEEP_TIME							13333
#define	TOGGLE_BUTTON						3

#include <MySensors.h>


#ifdef SER_DEBUG
#define DEBUG_SERIAL(x) Serial.begin(x)
#define DEBUG_PRINT(x) Serial.print(x)
#define DEBUG_PRINTLN(x) Serial.println(x)
#else
#define DEBUG_SERIAL(x)
#define DEBUG_PRINT(x) 
#define DEBUG_PRINTLN(x) 
#endif

#define LED_PWM_PIN							5

#define CHILD_SINGLE_LED_SWITCH				51
#define CHILD_SINGLE_LED_SWITCH_TEXT		(F("Switch"))




#define MAX_LED_LEVEL						1
#define LED_LEVEL_EEPROM					0
#define	BLINK_DELAY							180


bool justReceived = false;
uint8_t	lastLevel = 1;
uint32_t wakeupTime = 0;
uint32_t waitBeforeNextSleep = 5000;
volatile uint8_t currentLevel = 0; 			// Current LED level 0 or 1

MyMessage msgSwitchState					(CHILD_SINGLE_LED_SWITCH,		V_STATUS);			//51


void preHwInit() 
{
	DEBUG_SERIAL(MY_BAUD_RATE);
	pinMode(LED_PWM_PIN, OUTPUT);   // sets the pin as output
	pinMode(TOGGLE_BUTTON, INPUT_PULLUP);   // sets the pin as output
	DEBUG_PRINTLN("preHwInit done");

}

void before() 
{
	digitalWrite( LED_PWM_PIN, currentLevel );
}


void setup()
{
	DEBUG_PRINTLN("Setup");
}

void presentation()
{
	sendSketchInfo(SKETCH_NAME, SKETCH_VER );
	present(CHILD_SINGLE_LED_SWITCH, 	S_BINARY, 		CHILD_SINGLE_LED_SWITCH_TEXT);
}


void loop()
{
	uint32_t currentTime = millis();
	if (justReceived)//
	{
		DEBUG_PRINTLN("justReceived");
		justReceived = false;
	}
	
	if (lastLevel != currentLevel) 
	{
		lastLevel = currentLevel;
		setLED(currentLevel);
	}
	
	if ((currentTime - wakeupTime) > waitBeforeNextSleep)
	{
		DEBUG_PRINTLN("_");
		if (currentLevel == 0)
		{
			DEBUG_PRINTLN("prepare to sleep");
			int8_t wakeupReason = sleep(digitalPinToInterrupt(TOGGLE_BUTTON), FALLING , SLEEP_TIME, true);
			if (wakeupReason == digitalPinToInterrupt(TOGGLE_BUTTON))
			{
				currentLevel = 1;
				DEBUG_PRINTLN("LED on after wake by ButtonIRQ");
			}
			wakeupTime = millis();
			DEBUG_PRINT("leaving sleep: wakeup reason: ");
			DEBUG_PRINTLN(wakeupReason);
		}
	}
	else
	{
		DEBUG_PRINT(".");
	}
}



void receive(const MyMessage &message)
{
	DEBUG_PRINT( "receive: " );
	DEBUG_PRINTLN( message.getByte() );	
	if (message.type == V_STATUS) 
	{
		justReceived = true;
		uint8_t requestedLevel = message.getByte();
		if (requestedLevel == 0)
		{
			currentLevel=0;
		}
		else
		{
			currentLevel=1;
		}
	}
}


void setLED(uint8_t newLevel)
{
	DEBUG_PRINT( "setLED: " );
	DEBUG_PRINTLN( newLevel );	
	if (newLevel == 0)
	{
		analogWrite(LED_PWM_PIN,0);
	}
	else
	{
		analogWrite(LED_PWM_PIN,newLevel<<3);
	}
	send( msgSwitchState.set(currentLevel) );
}

15:06:44.843 -> setLED: 0
15:06:44.843 -> 3224 TSF:MSG:SEND,110-110-0-0,s=51,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:0
15:06:44.843 -> prepare to sleep
15:06:44.843 -> 3230 MCO:SLP:MS=13333,SMS=1,I1=1,M1=2,I2=255,M2=255
15:06:44.843 -> 3238 TSF:MSG:SEND,110-110-0-0,s=255,c=3,t=32,pt=5,l=4,sg=0,ft=0,st=OK:500
15:06:45.346 -> 3745 TSF:TDI:TSL
15:07:00.209 -> 3746 MCO:SLP:WUP=-1
15:07:00.209 -> 3748 TSF:TRI:TSB
15:07:00.209 -> 3757 TSF:MSG:SEND,110-110-0-0,s=255,c=3,t=33,pt=5,l=4,sg=0,ft=0,st=OK:13333
15:07:00.209 -> leaving sleep: wakeup reason: -1
15:07:00.209 -> prepare to sleep
15:07:00.209 -> 3764 MCO:SLP:MS=13333,SMS=1,I1=1,M1=2,I2=255,M2=255
15:07:00.209 -> 3774 TSF:MSG:SEND,110-110-0-0,s=255,c=3,t=32,pt=5,l=4,sg=0,ft=0,st=OK:500
15:07:00.275 -> 3817 TSF:MSG:READ,0-0-110,s=51,c=1,t=2,pt=0,l=1,sg=0:1
15:07:00.275 -> receive: 1
15:07:00.711 -> 4281 TSF:TDI:TSL
15:07:15.543 -> 4282 MCO:SLP:WUP=-1
15:07:15.543 -> 4284 TSF:TRI:TSB
15:07:15.577 -> 4292 TSF:MSG:SEND,110-110-0-0,s=255,c=3,t=33,pt=5,l=4,sg=0,ft=0,st=OK:13333
15:07:15.577 -> leaving sleep: wakeup reason: -1
15:07:15.577 -> justReceived
15:07:15.577 -> setLED: 1
15:07:15.577 -> 4301 TSF:MSG:SEND,110-110-0-0,s=51,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1

[rejoe2]

@tmandel said in disable/cancel smartSleep while sleep countdown is running:

In my opinion there should be 2 solutions for that problem

1. FHEM sends new values after I_POST_SLEEP_NOTIFICATION
2. in mysensors there is a method to cancel smartSleep countdown

My first attempt was to built to FHEM code like you suggested in #1. But this led to lost messages in the end, most likely due to interferring RF signals. This is the background why I was very interested in deeper insights on possibilities to cancel/delay the node's going asleep, because imo this would be the cleaner implementation.
I'm not too deep im C coding, but perhaps as trial to achieve #2 you could just call _process() from within the receive function (as the last statement)?

[tmandel]

@rejoe2 Thanks for your effort with trying to change the FHEM Module.
I think I found a way to cancel the smartSleep counter.

In MySensorsCore.cpp in line 619 I changed

wait(MY_SMART_SLEEP_WAIT_DURATION_MS);		// listen for incoming messages

to

if (wait(MY_SMART_SLEEP_WAIT_DURATION_MS, C_SET, I_VERSION)) //cancel sleeping request if there is a new C_SET Command
{
	CORE_DEBUG(PSTR("smartsleep canceled\n"));
	return MY_SLEEP_NOT_POSSIBLE;
}

This seems to work in MySenors but in FHEM the state says "asleep".
FHEM sends no more messages. Instead it increases the retainedMessages counter.

Even if I change the code to send I_POST_SLEEP_NOTIFICATION before cancel the smartSleep.

if (wait(MY_SMART_SLEEP_WAIT_DURATION_MS, C_SET, I_VERSION)) //cancel sleeping request if there is a new C_SET Command
{
	(void)_sendRoute(build(_msgTmp, GATEWAY_ADDRESS, NODE_SENSOR_ID, C_INTERNAL,
					   I_POST_SLEEP_NOTIFICATION).set(MY_SMART_SLEEP_WAIT_DURATION_MS + 20));
	CORE_DEBUG(PSTR("smartsleep canceled\n"));
	return MY_SLEEP_NOT_POSSIBLE;
}

Maybe we need a new internal message I_SMARTSLEEP_CANCELED.

Do you have an other idea?

[rejoe2]

Wow, very impressive code change!
Imo sending the post-sleep notification should at least lead to the node beeing indicated as "awoken" in FHEM. But as already mentionned, all new messages towards the nodes need a new pre-sleep-notification.
So you at first will have to send this type of message; if this message is lost, this will also lead to an increasing nr. of retained messages when "sending" out new info (the queue will be extended, but nothing really send out).

To create a new status like "awoken and ready to receive" might be a good idea; to change the FHEM-code for support of that kind of feature would not be a big issue (at least I hope so :grin: ).

[jlaraujo]

Regarding the post sleep message, i believe that the current controllers programming (certainly Domoticz and FHEM it seems) should accept the POST_SLEEP_MESSAGE as an indication that the node is ready to receive messages.
My understanding of the PRE_SLEEP_MESSAGE was to allow very recent messages to be received by the node, instead it seems that the controllers implementations assume that the node will only receive messages during that period.

A clarification in the Mysensors documentation to better describe the SmartSleep design would help to sort these behaviors.

[rejoe2]

@jlaraujo said in disable/cancel smartSleep while sleep countdown is running:

Regarding the post sleep message, i believe that the current controllers programming (certainly Domoticz and FHEM it seems) should accept the POST_SLEEP_MESSAGE as an indication that the node is ready to receive messages.

Some additional remarks on the FHEM code:
Indeed, as soon as the POST_SLEEP_MESSAGE is received, all new messages will be sent out without enqueueing (additionally, also requesting data will lead to direct sending of all new info until PRE_SLEEP_MESSAGE is received + a waiting time has elapsed).
But: direct sending out enqueued messages after reption of POST_SLEEP has turned out to be not a good idea, as already mentionned. This is why imo this message as such isn't a good criteria to decide about sending out enqueued data.
Perhaps it could be a good idea to start sending also enqueued info before the PRE_SLEEP, but only in rare cases we know the node to wait for info from controller side (e.g. after request time or status info messages).
Other option could be to define an individual waiting period per node after PRE_SLEEP to start sending (new Attribute).

@tmandel : Please let me know if either way would help. In any case, I'd need someone to do testing in case of code changes in that part. Programming timer functions not killing fhem in some rare cases turnded out to be a tricky job :grimacing: .
In any case, it could be a way around your troubles to request most recent info before going to sleep.

[tmandel]

@rejoe2
would it be possible to send out all queued messages if the controllers receives a heartbeat from the node? Maybe this should be a good solution, event if last POST_SLEEP_MESSAGE got lost. We dont have to invent new message types.

I could test your code on my development FHEM system.

Like @jlaraujo said I would like to know what the main-develepers of mysensors have to say about the prefered design of smartSleep.

[rejoe2]

@tmandel said in disable/cancel smartSleep while sleep countdown is running:

@rejoe2
would it be possible to send out all queued messages if the controllers receives a heartbeat from the node? Maybe this should be a good solution, event if last POST_SLEEP_MESSAGE got lost. We dont have to invent new message types.

I could test your code on my development FHEM system.

Using heartbeat imo is a good idea. This usually isn't used in smartSleeping nodes (smartsleep signals themselves renew alive state), so we could easily use that as a "deliever what you have" request.
Additionally, I have also changed other parts of the logic a bit: in case any information is sent out while node is alive will initiate also sending the queue, so e.g. any kind of requesting data would have the same result as heartbeat (or even a "by-accident at the right time" sending trial)...

So here's a completely untested version. "Should" work, but no guarantee:
https://github.com/rejoe2/FHEM/blob/master/10_MYSENSORS_DEVICE.pm

[rejoe2]

update: above mentionned module has been updated and now should load without trouble

[tmandel]

For those who are interested.
At the moment my patch runs quiet good.

@mfalkvidd maybe you can copy this patch to the developement branch of mysensors.

I don't know if the CORE_DEBUG text meets the guidelines.
This patch needs a new #define to wait some time before sending a new awake message to the controller.
If time is to short sometimes asleep and awake where executed reversed by the controller.

#define MY_SMART_SLEEP_REVOKE_WAIT_DURATION_MS (300ul)

//Tmandel: MySensorsCore.cpp Line 619
// wait(MY_SMART_SLEEP_WAIT_DURATION_MS);		// listen for incoming messages
if (wait(MY_SMART_SLEEP_WAIT_DURATION_MS, C_SET, I_VERSION)) //cancel sleeping request if there is a new C_SET Command
{
	#define MY_SMART_SLEEP_REVOKE_WAIT_DURATION_MS (300ul) 	// 300 seems to be OK (smaller values let the controller think that the node is still sleeping)
	CORE_DEBUG(PSTR("!MCO:SLP:RVKE\n")); //sleep revoked
	wait(MY_SMART_SLEEP_REVOKE_WAIT_DURATION_MS);
	CORE_DEBUG(PSTR("MCO:SLP:WUP=%" PRIi8 "\n"), MY_SLEEP_NOT_POSSIBLE);	// inform controller about wake-up
	(void)_sendRoute(build(_msgTmp, GATEWAY_ADDRESS, NODE_SENSOR_ID, C_INTERNAL,
					   I_POST_SLEEP_NOTIFICATION).set(MY_SMART_SLEEP_WAIT_DURATION_MS + MY_SMART_SLEEP_REVOKE_WAIT_DURATION_MS));
	return MY_SLEEP_NOT_POSSIBLE;
}
				

@rejoe2 Thank you for your effort with patching the FHEM module.

[rejoe2]

@tmandel

@rejoe2 Thank you for your effort with patching the FHEM module.

You're wellcome!

Wrt your patch: To get that into the mysensors repo, you'll have to use the (very painfull, but due to copyright reasons necessary) regular github mechanisms to get registered as kind of mysensors developer. Then you can send it as a pull request against the MySensors repo. As you use a new flag (?), you'll have to add some short decription wrt that also.
I'm not very familiar with all these processes, but in case you need help wrt that you may also contact me via FHEM forum for assistance.

Btw: Good job!:clap: :clap: :clap: