MY_TRANSPORT_DONT_CARE_MODE
-
@okos I don't see MY_TRANSPORT_WAIT_READY_MS in your sketch. Did you set it somewhere else?
And, again, debug output is usually very useful.
-
@okos, you have to set the state directly after sending. Something like this:
if (value != oldValue) { state = !state; send(msg.set(state), false); // We don't care about receiving ack...... digitalWrite(RELAY_PIN, state ? RELAY_ON : RELAY_OFF); // Store state in eeprom saveState(CHILD_ID, state); } -
@mfalkvidd
Better start from the beginning.
What I need to change in the code or configurations (MyConfig.h) to work the physical switch when the failure of the gateway.
Thank You@okos said:
I would like to ask whether it is normal that the switch does not work if the server domoticz off? I want to use the switch only crash server :flushed: now i cant"
Yes that is correct. The "relay with button actuator" sketch relies on an ack back from the controller to do the actual switching. so if the Gateway or Controller go down the local switch will also no longer work
And i got a reply from @hek it will be in the new library.(post 90)
Now i see 2.1.0 , and i have question now it is work?MY_TRANSPORT_DONT_CARE_MODE has been deprecated and did not make it into MySensors 2.1. As @Fabien has said you now need to use MY_TRANSPORT_WAIT_READY_MS instead.
What I need to change in the code or configurations (MyConfig.h) to work the physical switch when the failure of the gateway.
You have two choices, you can modify your MyConfig.h file or Define the change at the top of your sketch.
If You have a look at the MyConfig.h file you will see that at around line 179 is the area you need to be looking at. The default value is 0 which means no timeout so the sketch will not proceed to the loop part if a connection is not established.
However I think the best solution will be to Define the change in your sketch rather than change your config file.I have not used MY_TRANSPORT_WAIT_READY_MS before but it most likely will need to be added to the top of your sketch before the #include <MySensors.h> line.
Like this
// Enable debug prints to serial monitor #define MY_DEBUG // Enable and select radio type attached #define MY_RADIO_NRF24 // Enabled repeater feature for this node #define MY_REPEATER_FEATURE //set how long to wait for transport ready. in milliseconds #define MY_TRANSPORT_WAIT_READY_MS 3000 #include <SPI.h> #include <MySensors.h> #include <Bounce2.h>As this is only run once when the node first boots up you should allow plenty of time to start up normally if a connection is available. In the example above I have used 3 seconds but you may need to play with that to give your sketch the best chance of getting a connection without waiting too long.
As noted earlier in my post even once you get your sketch to run the loop the switch still will not work without a connection to the controller. So you will need to make some other changes to the sketch as well.
@hek Has given you a good start with the code modifications needed with the post above. There will be other issues to consider such as keeping the controller in sync with the node but best to get the basics right first then add the extras later.
-
@okos said:
I would like to ask whether it is normal that the switch does not work if the server domoticz off? I want to use the switch only crash server :flushed: now i cant"
Yes that is correct. The "relay with button actuator" sketch relies on an ack back from the controller to do the actual switching. so if the Gateway or Controller go down the local switch will also no longer work
And i got a reply from @hek it will be in the new library.(post 90)
Now i see 2.1.0 , and i have question now it is work?MY_TRANSPORT_DONT_CARE_MODE has been deprecated and did not make it into MySensors 2.1. As @Fabien has said you now need to use MY_TRANSPORT_WAIT_READY_MS instead.
What I need to change in the code or configurations (MyConfig.h) to work the physical switch when the failure of the gateway.
You have two choices, you can modify your MyConfig.h file or Define the change at the top of your sketch.
If You have a look at the MyConfig.h file you will see that at around line 179 is the area you need to be looking at. The default value is 0 which means no timeout so the sketch will not proceed to the loop part if a connection is not established.
However I think the best solution will be to Define the change in your sketch rather than change your config file.I have not used MY_TRANSPORT_WAIT_READY_MS before but it most likely will need to be added to the top of your sketch before the #include <MySensors.h> line.
Like this
// Enable debug prints to serial monitor #define MY_DEBUG // Enable and select radio type attached #define MY_RADIO_NRF24 // Enabled repeater feature for this node #define MY_REPEATER_FEATURE //set how long to wait for transport ready. in milliseconds #define MY_TRANSPORT_WAIT_READY_MS 3000 #include <SPI.h> #include <MySensors.h> #include <Bounce2.h>As this is only run once when the node first boots up you should allow plenty of time to start up normally if a connection is available. In the example above I have used 3 seconds but you may need to play with that to give your sketch the best chance of getting a connection without waiting too long.
As noted earlier in my post even once you get your sketch to run the loop the switch still will not work without a connection to the controller. So you will need to make some other changes to the sketch as well.
@hek Has given you a good start with the code modifications needed with the post above. There will be other issues to consider such as keeping the controller in sync with the node but best to get the basics right first then add the extras later.
-
@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?
