- Sat Aug 06, 2016 1:58 pm
#52313
Firstly, that [BROADCAST] code I gave you was meant as a replacement for the existing [BROADCAST] subroutine in order to make the local Broadcast message Send facility work correctly to manually broadcast messages to other nodes (and the debugger) for test purposes etc - so it wasn't for adding, it was for overwriting.
It allows you to locally send commands to other named nodes in exactly the same way that you can from the debugger utility. The message which is broadcast is whatever you enter into the message window (which I believe by default is ALL BLINKS) then click the Send button.
So you could send "Node140 ON" to see if your new node can receive and action it, or alternatively you could send the same message from the debugger utility... either way, if the named node is online it should action the command, which proves it is ok.
But that isn't how you are controlling Node146 from the master is it... you have hard-coded udpwrite 'On' and 'Off' commands specifically addressed to Node146 into the relevent subroutines of Node210, therefore when those messages get sent, only that specific named node will respond... even though all the other nodes should hear the same message but ignore it because it's not meant for them.
If you want to cause other nodes to take actions as well, you need to add other udpwrite commands specifically addressing those other required node(s) with the required command(s).
So effectively you need to shout an instruction to node146 for it to respond to, then you need to separately shout an instruction to node 140 for it to respond to. And if you later add a voice announcer node, you will need to shout another instruction specifically at that for it to respond to. And don't forget that they will each respond in the order you shout at them.
If you know the commands are always going to be the same that you want transmitted to a group of nodes, then you can address a single common message to their group name rather than repeating it for a list of individual unique names, so all members of that group name will recognise that they each need to action the same message.
The default group name is 'ALL', so sending "ALL BLINKS" will cause each node in the ALL group to blink (in case you're trying to physically locate them). If you only want to find a particular node, you address it by its unique node name, ie: node210 blinks.
That's why I made the point that it's worth giving some thought to node and group names before you start hard-coding names into the nodes and making it much harder to optimise later.
EasyNet nodes don't use IP addresses as such, but by default they do create a unique node name from the IP address to avoid duplicate default names - but that was only done for prudence, you'd be better advised to assign them meaningful names, such as ACmaster, ACslave1, etc.
This may seem a moot point at the moment, but consider what would happen if they lost their dhcp leased addresses and were assigned different ones when they reboot in the future after a power failure or router replacement, their newly created names may no longer correspond to the address names you've hard-coded messages to.
So don't forget that you can change any and all of the various defaults and save them to non-volatile flash if you wish, and they will automaticall keep their assigned names etc even after a reboot.
I'm deliberately giving you more info than you may need at this moment so that you might better take advantage of some of the EasyNet functionality which may not be so obvious or apparent. But you're already doing well Joe, and I'm pleased with where you're going with it.
It allows you to locally send commands to other named nodes in exactly the same way that you can from the debugger utility. The message which is broadcast is whatever you enter into the message window (which I believe by default is ALL BLINKS) then click the Send button.
So you could send "Node140 ON" to see if your new node can receive and action it, or alternatively you could send the same message from the debugger utility... either way, if the named node is online it should action the command, which proves it is ok.
But that isn't how you are controlling Node146 from the master is it... you have hard-coded udpwrite 'On' and 'Off' commands specifically addressed to Node146 into the relevent subroutines of Node210, therefore when those messages get sent, only that specific named node will respond... even though all the other nodes should hear the same message but ignore it because it's not meant for them.
If you want to cause other nodes to take actions as well, you need to add other udpwrite commands specifically addressing those other required node(s) with the required command(s).
So effectively you need to shout an instruction to node146 for it to respond to, then you need to separately shout an instruction to node 140 for it to respond to. And if you later add a voice announcer node, you will need to shout another instruction specifically at that for it to respond to. And don't forget that they will each respond in the order you shout at them.
If you know the commands are always going to be the same that you want transmitted to a group of nodes, then you can address a single common message to their group name rather than repeating it for a list of individual unique names, so all members of that group name will recognise that they each need to action the same message.
The default group name is 'ALL', so sending "ALL BLINKS" will cause each node in the ALL group to blink (in case you're trying to physically locate them). If you only want to find a particular node, you address it by its unique node name, ie: node210 blinks.
That's why I made the point that it's worth giving some thought to node and group names before you start hard-coding names into the nodes and making it much harder to optimise later.
EasyNet nodes don't use IP addresses as such, but by default they do create a unique node name from the IP address to avoid duplicate default names - but that was only done for prudence, you'd be better advised to assign them meaningful names, such as ACmaster, ACslave1, etc.
This may seem a moot point at the moment, but consider what would happen if they lost their dhcp leased addresses and were assigned different ones when they reboot in the future after a power failure or router replacement, their newly created names may no longer correspond to the address names you've hard-coded messages to.
So don't forget that you can change any and all of the various defaults and save them to non-volatile flash if you wish, and they will automaticall keep their assigned names etc even after a reboot.
I'm deliberately giving you more info than you may need at this moment so that you might better take advantage of some of the EasyNet functionality which may not be so obvious or apparent. But you're already doing well Joe, and I'm pleased with where you're going with it.
