Filter node

[Snyfir]

Hello,

I have two nodes repeater with battery and one node repeater without battery.

Instead of all node can pass throw all repeater nodes, i want for some particular node to pass throw only by repeater with battery.

Is it possible to do it, without modify a lot of code of MySensors ?

I was thinking to filter by node ID. For example, if a node as an ID below 100, the repeater without battery will not respond to I_FIND_PARENT message. So, the node will not use the repeater without battery. Is it a good approach?

[Snyfir]

Something like that can works ?

MyTransport.cpp::transportProcessMessage(void)

} else if (destination == BROADCAST_ADDRESS) {
		TRANSPORT_DEBUG(PSTR("TSF:MSG:BC\n"));	// broadcast msg
		if (command == C_INTERNAL) {
			if (isTransportReady()) {
				// only reply if node is fully operational
				if (type == I_FIND_PARENT_REQUEST) {
#if defined(MY_REPEATER_FEATURE)

                    #if defined(MY_REPEATER_FEATURE_WITHOUT_BATTERY)
                    if (sender < 100) {
                        return;
                    }
                    #endif

					if (sender != _transportConfig.parentNodeId) {	// no circular reference
						TRANSPORT_DEBUG(PSTR("TSF:MSG:FPAR REQ,ID=%" PRIu8 "\n"), sender);	// FPAR: find parent request
						// check if uplink functional - node can only be parent node if link to GW functional
						// this also prevents circular references in case GW ooo
						if (transportCheckUplink()) {
							_transportSM.lastUplinkCheck = hwMillis();
							TRANSPORT_DEBUG(PSTR("TSF:MSG:GWL OK\n")); // GW uplink ok
							// random delay minimizes collisions
							delay(hwMillis() & 0x3ff);
							(void)transportRouteMessage(build(_msgTmp, sender, NODE_SENSOR_ID, C_INTERNAL,
							                                  I_FIND_PARENT_RESPONSE).set(_transportConfig.distanceGW));
						} else {
							TRANSPORT_DEBUG(PSTR("!TSF:MSG:GWL FAIL\n")); // GW uplink fail, do not respond to parent request
						}
					}
#endif
					return; // no further processing required, do not forward
				}
			} // isTransportReady

[BearWithBeard]

What about using MY_PARENT_NODE_ID on the nodes that should connect to a specific repeater? If you also want to prevent the node to connect to other repeaters as a fall back in case the specified parent is unavailable, combine it with MY_PARENT_NODE_IS_STATIC.

#define MY_PARENT_NODE_ID 2 // Set node 2 as preferred parent
#define MY_PARENT_NODE_IS_STATIC // Disables fall back

[TheoL]

@Snyfir Hello my friend,

I'm not the one who's deep into the Mysensors code. But I assume you have to either clone it from github and adjust the code. Which means you'll have to merge all fixes and changes yourself to your clone.
Or you have to implement your own repeater code. But not sure if that is possible. Because I don't think your sketch receives all the messages not intended for the node itself.

I'm not really sure why you'd want this. But I don't know the problem you're trying to solve. As I've always understood it. Each node would always try to connect to the gateway first. If that is not possible it will try to find a repeater.

So if your particular node can not reach the battery powered repeater. It will have no connection to the gateway at all I suppose.

What @BearWithBeard suggests might be an easier fix. But you have to be really sure your node can always contact the battery operated repeater.

[Snyfir]

Thank you for your answer @BearWithBeard.
I don't want to use this solution because it will stuck my nodes to use only the same parent and i don't want because i have several repeaters, and my nodes are likely to move from room to another room.

[mfalkvidd]

@Snyfir could you share more details on why you don’t want to go through that repeater?

[Snyfir]

I want to have a network (A) which will not stop working when the power of the house is down. Because I have door sensor for the alarm of the house.

And I want another network (B) which can be down when the power is off because it is not for security (temperature, humidity sensor…). This network needs to used the repeater of the network A also.

That’s why I want nodes of network (A) use only repeaters of network (A), and nodes of network (B) use repeaters of networks (A) and (B)

[evb]

@Snyfir another approach is to use another radio channel for your B network? That includes of course another gateway also...
An advantage is that you can stick with the standard MySensors library.
More information on : https://www.mysensors.org/download/sensor_api_20 : search channel

of course:
That’s why I want nodes of network (A) use only repeaters of network (A), and nodes of network (B) use repeaters of networks (A) and (B)
This will not be possible....

[TheoL]

In all honesty mixing rfm69 and nrf24L01+, as @evb, suggests seems to me to be a way that isn't complicated and doesn't acquire any additional coding. I think I'd go that route

[evb]

@TheoL sorry, I didn't have that in mind, but of course that is also a possibility.

With the RF24, we can configure another channel

/**
 * @def MY_RF24_CHANNEL
 * @brief RF channel for the sensor net, 0-125.
 *
 * Frequencies: 2400 Mhz - 2525 Mhz
 *
 * Channels: 126
 * @see https://www.nordicsemi.com/eng/nordic/download_resource/8765/2/42877161/2726
 *
 * - 0 => 2400 Mhz (RF24 channel 1)
 * - 1 => 2401 Mhz (RF24 channel 2)
 * - 76 => 2476 Mhz (RF24 channel 77)
 * - 83 => 2483 Mhz (RF24 channel 84)
 * - 124 => 2524 Mhz (RF24 channel 125)
 * - 125 => 2525 Mhz (RF24 channel 126)
 *
 * In some countries there might be limitations, in Germany for example only the range
 * 2400,0 - 2483,5 Mhz is allowed.
 * @see http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2013_10_WLAN_2,4GHz_pdf.pdf
 */
#ifndef MY_RF24_CHANNEL
#define MY_RF24_CHANNEL (76)
#endif

/**

If we use RFM69 radio, we can define the network ID

#define 	MY_RFM69_NETWORKID   (100)
 	RFM69 Network ID. Use the same for all nodes that will talk to each other.

[Snyfir]

I understand what you said. For further project I wild I think used two channels.
But right now, I don’t want to change the hardware. If nobody can tell me if the solution i propose in post 2 works, I will try it.

[mfalkvidd]

@Snyfir thanks for explaining. How come you want the B sensors to be disabled when the power is off? Why can’t they be allowed to continue working?

[Snyfir]

@mfalkvidd said in Filter node:

@Snyfir thanks for explaining. How come you want the B sensors to be disabled when the power is off? Why can’t they be allowed to continue working?

I don't want the B sensors to be disable when the power is off. It's juste because sensors B is not on battery and if the power of the house is off, sensors B can't works

[mfalkvidd]

@Snyfir if they can't work anyway, why do you want to filter them?

[Snyfir]

@mfalkvidd said in Filter node:

@Snyfir if they can't work anyway, why do you want to filter them?

I don't want that repeaters without battery are used by security nodes (door status, PIR...). Because if the power of the house is down, security nodes while not works during a moment.
That's why i want repeaters without battery to reject security nodes

[alexelite]

@Snyfir In your first post you say that only one node is mains powered. Instead of modifying the library, why not provide a UPS type power supply for that node. Something with an old phone battery or 1-2 18650 cells.
But I guess the other two already have something like this, they are not battery only.
That way if the power goes down all your repeaters are up.

[TheoL]

In all honesty, I'm not quite convinced you'd need two separate networks. Just provide the security sensors, the repeaters, the gateway and your controller - that form the security system - with some sort of ups and they will keep running until the UPS has no more power left.
The none security devices will stop working when the power goes out and, unless I don't really understand your problem well. That does what I think you want to achieve? Unless you have combined a lot of sensors within a repeater it would really be my way to go. It wouldn't mean any modifications to your security hardware, because they need to be battery powered or have some sort of UPS anyway, to keep working when the power goes down.
But again it's hard to judge when you don't really understand the problem some one is trying to solve.