MY_TRANSPORT_DONT_CARE_MODE

[okos]

Hello, two month ago i asked question

In this topic: https://forum.mysensors.org/topic/3671/ac-dc-double-solid-state-relay-module/93

"Hello.
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 now i cant"

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?

Thank You

[Fabien]

set MY_TRANSPORT_WAIT_READY_MS to something different to 0.

[okos]

@Fabien

Still is problem with physical button when gateway is not responsible.( i can not off and on the lights )
For example, when a server domoticz failure.

[mfalkvidd]

@okos could you describe the problem in a bit more detail? What happens? What was expected to happen?

Debug logs are usually very useful, especially together with sketch code.

[okos]

@mfalkvidd
I would like to control physical switch even if the gateway is unavailable (use domoticz and this project https://www.openhardware.io/view/77/AC-DC-double-solid-state-relay-module).

Now physical switch works only when is communicating with the gateway.

Thank You

// Example sketch för a "light switch" where you can control light or something 
// else from both vera and a local physical button (connected between digital
// pin 3 and GND).
// This node also works as a repeader for other nodes

#define MY_RADIO_NRF24
#include <MySensors.h>
#include <SPI.h>
#include <Bounce2.h>
#include <OneWire.h>
#include <DallasTemperature.h>

#define RELAY_PIN    3  // Arduino Digital I/O pin number for relay 
#define RELAY_PIN_2  5
#define BUTTON_PIN   4  // Arduino Digital I/O pin number for button 
#define BUTTON_PIN_2 7
#define ONE_WIRE_BUS 8

#define CHILD_DSB_ID 13
#define CHILD_ID_2 12
#define CHILD_ID 11 // Id of the sensor child
#define RELAY_ON 1
#define RELAY_OFF 0

Bounce debouncer = Bounce();
int oldValue = 0;
bool state;
Bounce debouncer2 = Bounce();
int oldValue2 = 0;
bool state2;

MyMessage msg(CHILD_ID, V_LIGHT);
MyMessage msg2(CHILD_ID_2, V_LIGHT);
MyMessage msgTemp(CHILD_DSB_ID, V_TEMP);

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 


void presentation() {
	// Send the sketch version information to the gateway and Controller
	sendSketchInfo("Double Relay & Button", "0.2");
	// Register all sensors to gw (they will be created as child devices)
	present(CHILD_ID, S_LIGHT);
	present(CHILD_ID_2, S_LIGHT);
	present(CHILD_DSB_ID, S_TEMP);
}

void setup()
{
	sensors.begin();
	sensors.setWaitForConversion(false);

	// Setup the button
	pinMode(BUTTON_PIN, INPUT);
	// Activate internal pull-up
	digitalWrite(BUTTON_PIN, HIGH);

	// Setup the button
	pinMode(BUTTON_PIN_2, INPUT);
	// Activate internal pull-up
	digitalWrite(BUTTON_PIN_2, HIGH);

	// After setting up the button, setup debouncer
	debouncer.attach(BUTTON_PIN);
	debouncer.interval(5);

	debouncer2.attach(BUTTON_PIN_2);
	debouncer2.interval(5);


	// Make sure relays are off when starting up
	digitalWrite(RELAY_PIN, RELAY_OFF);
	// Then set relay pins in output mode
	pinMode(RELAY_PIN, OUTPUT);

	digitalWrite(RELAY_PIN_2, RELAY_OFF);
	// Then set relay pins in output mode
	pinMode(RELAY_PIN_2, OUTPUT);

	// Set relay to last known state (using eeprom storage) 
	state = loadState(CHILD_ID);
	digitalWrite(RELAY_PIN, state ? RELAY_ON : RELAY_OFF);

	state2 = loadState(CHILD_ID_2);
	digitalWrite(RELAY_PIN_2, state2 ? RELAY_ON : RELAY_OFF);

}


/*
*  Example on how to asynchronously check for new messages from gw
*/
void loop()
{
	static float prevTemp = 0;

	debouncer.update();
	debouncer2.update();
	// Get the update value
	int value = debouncer.read();
	int value2 = debouncer2.read();

	if (value != oldValue) {
		send(msg.set(state ? false : true), true); // Send new state and request ack back
	}
	oldValue = value;

	if (value2 != oldValue2) {
		send(msg2.set(state2 ? false : true), true); // Send new state and request ack back
	}
	oldValue2 = value2;

	// Fetch temperatures from Dallas sensors
	sensors.requestTemperatures();
	// Fetch and round temperature to one decimal
	float temperature = static_cast<float>(static_cast<int>(sensors.getTempCByIndex(0) * 10.f)) / 10.f;

	if (temperature != -127.00f && temperature != 85.00f && prevTemp != temperature) {
		// Send in the new temperature
		send(msgTemp.set(temperature, 1));
		Serial.print("Sent temperature: ");
		Serial.println(temperature);
		prevTemp = temperature;
	}
}

void receive(const MyMessage &message) {
	// We only expect one type of message from controller. But we better check anyway.
	if (message.isAck()) {
		Serial.println("This is an ack from gateway");
	}

	if (message.type == V_LIGHT && message.sensor == 11) {
		// Change relay state
		state = message.getBool();
		digitalWrite(RELAY_PIN, state ? RELAY_ON : RELAY_OFF);
		// Store state in eeprom
		saveState(CHILD_ID, state);
	}
	else if (message.type == V_LIGHT && message.sensor == 12) {

		state2 = message.getBool();
		digitalWrite(RELAY_PIN_2, state2 ? RELAY_ON : RELAY_OFF);
		// Store state in eeprom
		saveState(CHILD_ID_2, state2);


		// Write some debug info
		Serial.print("Incoming change for sensor:");
		Serial.print(message.sensor);
		Serial.print(", New status: ");
		Serial.println(message.getBool());
	}
}

[mfalkvidd]

@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]

@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

[hek]

@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);

     }

[Boots33]

@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 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.

[tekka]

@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.

[Boots33]

@tekka

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

[tekka]

@Boots33 said:

@tekka

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]

@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?

[mfalkvidd]

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.

[Boots33]

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.

[Reza]

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)

[mfalkvidd]

@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]

@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.

[DavidZH]

@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]

@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?