Option non blocking registration at gateway

[eric_smid]

Is it possible to make the registration at the gateway non blocking, so the node can start processing other things and send messages when the gateway is reachable.
Use case:
A node that switches lights and is mounted behind a switch in the wall. For emergency situations it should always be possible to switch on the lights even when the gateway fails.
When the switch is pressed, the node notifies the gateway the lights are switched on or off. The lights can also be switched on or off via the gateway.

[Yveaux]

@eric_smid said:

non blocking

This would require buffering of transmission messages, which currently isn't implemented in the library.
For your particular usecase I would handle the button presses in an interrupt handler, which triggers sending a message to the GW.
If updating the GW blocks and new button presses come in, the interrupt handler can always act on them.

[eric_smid]

Hi Yveaux. To my opinion it is not necesarry for the library to do the buffering.
I'm looking for an option where the node enters void loop() even if there is no gateway when the node boots, so it can do things locally.
Because there is no gateway, it is not possible to send or receive messages. It is no problem if they get lost.
For the node a user can create a buffer for messages that should be reported when the nodes detects a gateway is available.
The function isTransportOK() can for instance be use to discover if a gateway is available.
So I think it is only necesarry to implement an option to enter void(loop) when no gateway is detected and periodically try to register to the gateway.

[mfalkvidd]

I think what @eric_smid suggests can be an important feature. The manual control must work, even if the gateway is temporarily out of order. Otherwise the rest of the family will complain a lot.

[TheoL]

@mfalkvidd @Yveaux There was a similar discussion a couple of weeks ago. The gateway should always be reachable. Unless there's a power cut. But to be honest I don't know what happens then. Might take a couple of hours before my network is completely healed. Because the nodes might come up earlier than the gateway once the power is back on. Also the gateway might not be able to handle all the node registrations. But in those cases nodes need to register themselves with a random delay. Just to give the gateway the time to handle the load. Because I'm not convinced it can.

My personal statement is: Devices should work independently from your home automation if they are a vital part of your life. Like light and so. Home Automation and IoT should enhance your life, and not take over your life.

And to be honest. I don't see the need of buffering messages. Because the messages you'll be buffering might already be outdated when the gateway and your controller come up again. Meaning you could have switched the lights on and then off. So what would be the value of buffering the outdated data? We should just simply accept the fact that we've lost some sensor values. The data can be interpolated in the long run anyway. Which Domoticz already does, when it shows you the graphs.

I can't remember the last power cut we had over here. So to me losing some sensor values in a situation like that is acceptable. Certainly if all of my MySensors devices will keep working in a situation like this. Then loosing data isn't that bad.

This is also the reason why you should send the current state of sensors and actors on a regular basis to you controller. That way the controller and the nodes will be in synch again at some time, after a power cut.

This feature would indeed help us in creating a solution which enhances our lives instead of the opposite. But that's just my 50 cents. Curious how Z-waves handles this?

[eric_smid]

I have Z-wave modules (Fibaro) installed. The switches can be used without gateway.
When the gateway boots (I use Razzberry) it start detecting the nodes. I assume it it is up to the nodes to send the current state.
I agree that buffering messages is useless in most cases. A periodic update (initiated by the user program) is in my opinion the correct solution.

[sundberg84]

I would love to see an start on this - maybe a relay example that works without the gateway. As @TheoL said, lights - and i think thats one end to start. The best would offcourse be to make some generic thing that works for all nodes.

[Bogdan Brezuica]

I have the same issue with a gas sensor. I would really like the buzzer to sound even if the gateway is unreachable. Letting the home automation know there is a gas leak in order to take other measures wold be optimal but sounding the alarm is mandatory.

[hek]

It's only during startup the node does a handshake with the parent node (which can be disabled using MY_TRANSPORT_DONT_CARE_MODE in dev branch). During normal operation the library never block even if communication link is down.

[tekka]

Important: enabling MY_TRANSPORT_DONT_CARE_MODE requires setting MY_PARENT_NODE_ID

[eric_smid]

Great this option is available!
Is it possible to let the node use the last used parent, instead of configuring the parent?

[tekka]

@eric_smid No, not in the current implementation

[TheoL]

@hek Just curious. How important is the handshake? Because if it's important I think it would be a good option, to let node's do a delayed hand shake when the initial one fails. So that they can continue, but just won't use the my sensors part until a delayed handshake is done.

A delayed hand shake would only be needed when there's a power cut.

[Heizelmann]

Coming from this thread, where I learned that an implementation of this feature is in progress.

In my opinion it is an essential architectural feature. Reasons for this you can see above.

Here I summarize what I think is necessary:

General requirements

• Devices should work independently from the gateway
• Enter loop() even if gateway is not reachable
• Buffering of messages not necessary. Its up to the user to implement this.

Needed functionality

• retrieve available gateways (gets a list of available gateways)
• request to register ( gets success or failure with reason)
• de-register ( gets success or failure with reason)

[DavidZH]

@Heizelmann

I've been thinking about his as well. Probably for different reasons though.

I find myself with time to spare and my laptop at hand quite often, but I'm not home at those moments. I'd love to be able to write code and test sensors at those times, but that's impossible because there's no gateway.

For that I'd like to propose a "Test Mode".

• test port to Transport.
• NO connection to gateway.
• simulate the Transport calls in the sketch with just a line in the debug with ACK.
• when possible: send "messages" to node with the Arduino serial monitor.

I am aware that this might pose some biiiiiiig changes in the lib. So this might be something for the 2.5 or 3.0 release.
Thoughts?

[Heizelmann]

I am now ready with my node and I need the non-blocking feature urgently. Is there an estimation when this feature will be come or can anyone provide a workaround?

[hek]

If you use the development branch and want to prohibit the registration wait. Add

#define MY_TRANSPORT_WAIT_READY_MS 1

@tekka, correct me if I'm wrong please ;)

[tekka]

@hek correct :+1:
@Heizelmann Would be good to get some feedback on this feature, please let us know how it works in your hands.

[Heizelmann]

Here my report after a quick test.

To say it short: Generally I am happy with it, it works very well. Only one small problem.

In detail:
When connection is initially off, the sketch entered after the defined wait the loop.

before()
5 TSM:INIT
7 TSF:WUR:MS=1000
13 !TSM:INIT:TSP FAIL
15 TSM:FAIL:CNT=1
17 TSM:FAIL:PDT
1008 MCO:BGN:STP
Setup()
1510 MCO:BGN:INIT OK,TSP=0

If the sketch tries to send within the loop a message is logged.

145312 !MCO:SND:NODE NOT REG

If connection comes back the sketch connects to the gateway on the fly within the defined wait time.

244251 TSM:FPAR:OK
244252 TSM:ID
244254 TSM:ID:OK
244255 TSM:UPL
244259 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
244265 TSF:MSG:READ,0-0-42,s=255,c=3,t=25,pt=1,l=1,sg=0:1
244271 TSF:MSG:PONG RECV,HP=1
244274 TSM:UPL:OK
244276 TSM:READY:ID=42,PAR=0,DIS=1
244281 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
244288 TSF:MSG:READ,0-0-42,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
244295 TSF:MSG:SEND,42-42-0-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.1.0-beta
244304 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
244321 TSF:MSG:READ,0-0-42,s=255,c=3,t=6,pt=0,l=1,sg=0:M
Presentation()
244329 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=11,pt=0,l=22,sg=0,ft=0,st=OK:My Node
244339 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.2
244347 TSF:MSG:SEND,42-42-0-0,s=1,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
244356 TSF:MSG:SEND,42-42-0-0,s=2,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
244364 TSF:MSG:SEND,42-42-0-0,s=3,c=0,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
244370 MCO:REG:REQ
244373 TSF:MSG:SEND,42-42-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
244380 TSF:MSG:READ,0-0-42,s=255,c=3,t=27,pt=1,l=1,sg=0:1
244385 MCO:PIM:NODE REG=1

Only problem is that you get high logging traffic in the case when you are in loop and network connection gets lost again as long as the connection is lost.

605458 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605463 !TSF:MSG:LEN,0!=7
605465 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605470 !TSF:MSG:LEN,0!=7
605472 TSF:MSG:READ,1-1-1,s=1,c=1,t=1,pt=0,l=0,sg=0:
605477 !TSF:MSG:LEN,0!=7
...

[tekka]

@Heizelmann Thanks for your testing. I couldn't reproduce this behavior, can you post your sketch for further analysis?