MY_TRANSPORT_DONT_CARE_MODE
-
@Boots33 Thanks for summarizing this, one comment: if the node enters the main loop after the timeout it will still try to establish an uplink connection.
A couple of questions if I could
if the node establishes the uplink inside of the timeout period does it move on or will it still wait for the end of the timeout period?
The other question I have is with this feature and others like isTransportReady() are they just testing for a link between the node and gateway or all the way to the controller?
Thanks
-
A couple of questions if I could
if the node establishes the uplink inside of the timeout period does it move on or will it still wait for the end of the timeout period?
The other question I have is with this feature and others like isTransportReady() are they just testing for a link between the node and gateway or all the way to the controller?
Thanks
@Boots33 said:
A couple of questions if I could
if the node establishes the uplink inside of the timeout period does it move on or will it still wait for the end of the timeout period?
It will enter the main loop immediately
The other question I have is with this feature and others like isTransportReady() are they just testing for a link between the node and gateway or all the way to the controller?
Currently, only the link to the GW (but I have some ideas to extend this further)
-
@Boots33 said:
A couple of questions if I could
if the node establishes the uplink inside of the timeout period does it move on or will it still wait for the end of the timeout period?
It will enter the main loop immediately
The other question I have is with this feature and others like isTransportReady() are they just testing for a link between the node and gateway or all the way to the controller?
Currently, only the link to the GW (but I have some ideas to extend this further)
@tekka said:
Currently, only the link to the GW (but I have some ideas to extend this further)
A check back to the controller would be useful i think. I guess at the moment the best way to check if the controller is available would be to issue a request and then see if the data is returned?
-
Could we collect some use cases on where controller availability is useful?
From what I see, transportReady only tells whether connection was ready, not that it is ready. The code would still need to handle that the controller goes down before the next message is sent.
The suggested workaround, fetching a variable from the controller, has the same limitation. The node knows that the controller was available when the variable was sent, but the controller might not be available anymore.
If we add complexity to MySensors to solve a problem, we should have real use cases and make sure the use cases are supported by the new features. Otherwise we risk making MySensors harder to understand, troubleshoot and maintain without adding value.
-
While it would not likely be needed by most nodes I think for some, being able to test the integrity of the complete network would be a bonus.
These would most often be "mission critical" nodes that control things like heaters, pumps and sprinkler systems etc. For instance if a heater node was turned on by the controller it could make occasional checks for network availability and perhaps fall back to a fail safe mode if the network is lost.
I agree that MySensors should remain as lean as possible and the last thing i want is a network full of nodes constantly pinging, but I also think that in an environment aimed at automation the ability to confirm network integrity might at times be useful, if it can be implemented without too much complexity.
-
i have same problem . thanks all . MY_TRANSPORT_WAIT_READY_MS is a good way for this issue. but there is a small problem that if this is solve so relay with button is perfect performance. most time when i want turn on or off with button, for first push dont work.... and after 2 or 3 push relay work ( for both state. radio is connect or radio is not connect)
-
While it would not likely be needed by most nodes I think for some, being able to test the integrity of the complete network would be a bonus.
These would most often be "mission critical" nodes that control things like heaters, pumps and sprinkler systems etc. For instance if a heater node was turned on by the controller it could make occasional checks for network availability and perhaps fall back to a fail safe mode if the network is lost.
I agree that MySensors should remain as lean as possible and the last thing i want is a network full of nodes constantly pinging, but I also think that in an environment aimed at automation the ability to confirm network integrity might at times be useful, if it can be implemented without too much complexity.
@Boots33 said:
While it would not likely be needed by most nodes I think for some, being able to test the integrity of the complete network would be a bonus.
These would most often be "mission critical" nodes that control things like heaters, pumps and sprinkler systems etc. For instance if a heater node was turned on by the controller it could make occasional checks for network availability and perhaps fall back to a fail safe mode if the network is lost.
I like the heater use case. It gives us a tangible situation to discuss.
Can't the heater use case be solved with existing functionality? The heater can request its own state from the controller periodically. If it gets a response everything is fine. If it gets no response it enters fail safe mode. Would the proposed new functionalty add any value?
-
@Boots33 said:
While it would not likely be needed by most nodes I think for some, being able to test the integrity of the complete network would be a bonus.
These would most often be "mission critical" nodes that control things like heaters, pumps and sprinkler systems etc. For instance if a heater node was turned on by the controller it could make occasional checks for network availability and perhaps fall back to a fail safe mode if the network is lost.
I like the heater use case. It gives us a tangible situation to discuss.
Can't the heater use case be solved with existing functionality? The heater can request its own state from the controller periodically. If it gets a response everything is fine. If it gets no response it enters fail safe mode. Would the proposed new functionalty add any value?
@mfalkvidd Yes you are correct, requests for state, time etc can already be used to validate the connection to server but if this can be unified into an existing transport check without undue effort then that would be ok too.
I have not made a feature request for this to be done I was simply responding to a comment from Tekka that thoughts in this area may have already occurred.
Whether it should be done or not is well above my pay grade I'm afraid and I will gladly leave those decisions to those more qualified to do so. :)
-
@mfalkvidd said in MY_TRANSPORT_DONT_CARE_MODE:
Could we collect some use cases on where controller availability is useful?
I am changing my main light switches in the house for MySensorized ones to include extra's like notification of the house-state (at home, away, night), remote switching of some lights and the ceiling fan. If the controller (or just gateway for that matter) is down, the WAF would plummet like a boulder dropped from an airplane. Whatever happens, the light switches MUST ALWAYS FUNCTION!
Then when the link returns, the control must be passed over to the controller without states changing. "Oh, I think Pimatic is working again because the light goes off...." <- bad for WAF...
These light switches will be powered by the utility, so they can go search for a parent until hell freezes over, I dont care (as long as the switch function is working).
Battery powered sensors on the other hand do not have that luxury, because of the battery drain. So they could benefit from knowing link status also by searching for a parent once, and if none is found, go back to sleep for their usual schedule in a hurry! Do not even try to read or send a sensor value.Now I have planned two magentic door sensors on battery. That will prove difficult because these will not have a schedule to send once every few minutes. So I will have to build something for that. These will be part of a personal alarm system (no sirens, just push messages), so lots of empty batteries and false messages will drive down the WAF as well.
This has to be implemented in my controller (Pimatic in my case) as well. If Pimatic stops for some reason, the gateway has to stop as well. But that's something for another forum....
-
@mfalkvidd said in MY_TRANSPORT_DONT_CARE_MODE:
Could we collect some use cases on where controller availability is useful?
I am changing my main light switches in the house for MySensorized ones to include extra's like notification of the house-state (at home, away, night), remote switching of some lights and the ceiling fan. If the controller (or just gateway for that matter) is down, the WAF would plummet like a boulder dropped from an airplane. Whatever happens, the light switches MUST ALWAYS FUNCTION!
Then when the link returns, the control must be passed over to the controller without states changing. "Oh, I think Pimatic is working again because the light goes off...." <- bad for WAF...
These light switches will be powered by the utility, so they can go search for a parent until hell freezes over, I dont care (as long as the switch function is working).
Battery powered sensors on the other hand do not have that luxury, because of the battery drain. So they could benefit from knowing link status also by searching for a parent once, and if none is found, go back to sleep for their usual schedule in a hurry! Do not even try to read or send a sensor value.Now I have planned two magentic door sensors on battery. That will prove difficult because these will not have a schedule to send once every few minutes. So I will have to build something for that. These will be part of a personal alarm system (no sirens, just push messages), so lots of empty batteries and false messages will drive down the WAF as well.
This has to be implemented in my controller (Pimatic in my case) as well. If Pimatic stops for some reason, the gateway has to stop as well. But that's something for another forum....
@DavidZH those use cases are great, and I would really like to see strong support for them in MySensors. Spouse accpetance factor is very important.
However, I don't see that testing for a connection to the controller would help any of the use cases. Could you describe how the node would use information about whether the controller recently was available and do different things based on that result?
