Archived Forum

Hi Simon, 

The reference to "212" is the early rfm12pi's could only use upto 212 groups (255 are now available) hence the OEM standard of group 210. group 0 is promiscuous mode and should not really be used for a operational setup, it is a mode rather than a group id. 

When setting group 0 you are removing a huge chunk of filtering, the byte used to define the group has to matched in any incoming packet so it effectively extends the crc by another byte, setting group 0 doesn't mean match the "0" setting but ignores that byte so you may not only start receiving "other groups" if there are any to be found but significantly increase the chance of rogue packets getting through.

I do intend to make emonhub fit better with jeelib and will almost definitely accommodate the group 0 setting, but that will probably be in a debugging mode rather than allowing any group to be openly used.

I would be interested to see your emonhub.log at start up to see why the group is not being set by emonhub,

Is it set in the [[RFM2Pi]] [[[runtimesettings]]] in emonhub.conf?

Paul

I used minicom to make the change and the data is now landing fine  :-)

Here's my listener section of emonhub.conf

[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 9600
    [[[runtimesettings]]]
        group = 210
        frequency = 868
        baseid = 10

Here's some of the log file from earlier. Doesn't seem as if emonhub is making any impression on the RFM12Pi

This repeats for quite a while before the log turns over to reporting the non numeric error because of the 'G'

2016-01-09 09:55:55,796 DEBUG 61 NEW FRAME : 1452333355.8 Available commands:
2016-01-09 09:55:56,142 WARNING 61 Discarded RX frame 'non-numerical content' : ['Available', 'commands:']
2016-01-09 09:55:56,435 DEBUG 62 NEW FRAME : 1452333356.43   123 x      - Toggle configuration change protection, 1=Unlocked
2016-01-09 09:55:56,438 WARNING 62 Discarded RX frame 'non-numerical content' : ['123', 'x', '', '', '', '', '', '-', 'Toggle', 'configuration', 'change', 'protection,', '1=Unlocked']
2016-01-09 09:55:56,687 DEBUG 63 NEW FRAME : 1452333356.69   <nn> i     - set node ID (standard node ids are 1..26)
2016-01-09 09:55:56,690 WARNING 63 Discarded RX frame 'non-numerical content' : ['<nn>', 'i', '', '', '', '', '-', 'set', 'node', 'ID', '(standard', 'node', 'ids', 'are', '1..26)']
2016-01-09 09:55:56,953 DEBUG RFM2Pi device settings updated:   <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2016-01-09 09:55:57,196 DEBUG 64 NEW FRAME : 1452333357.2   <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2016-01-09 09:55:57,200 WARNING 64 Discarded RX frame 'non-numerical content' : ['<nnn>', 'g', '', '', '', '-', 'set', 'network', 'group', '(RFM12', 'only', 'allows', '212,', '0', '=', 'any)']
2016-01-09 09:55:57,482 DEBUG 65 NEW FRAME : 1452333357.48   <n> c      - set collect mode (advanced, normally 0)
2016-01-09 09:55:57,485 WARNING 65 Discarded RX frame 'non-numerical content' : ['<n>', 'c', '', '', '', '', '', '-', 'set', 'collect', 'mode', '(advanced,', 'normally', '0)']
2016-01-09 09:55:57,727 DEBUG 66 NEW FRAME : 1452333357.73   ...,<nn> a - send data packet to node <nn>, with ack
2016-01-09 09:55:57,731 WARNING 66 Discarded RX frame 'non-numerical content' : ['...,<nn>', 'a', '-', 'send', 'data', 'packet', 'to', 'node', '<nn>,', 'with', 'ack']
2016-01-09 09:55:57,975 DEBUG 67 NEW FRAME : 1452333357.97   ...,<nn> s - send data packet to node <nn>, no ack
2016-01-09 09:55:57,978 WARNING 67 Discarded RX frame 'non-numerical content' : ['...,<nn>', 's', '-', 'send', 'data', 'packet', 'to', 'node', '<nn>,', 'no', 'ack']
2016-01-09 09:55:58,239 DEBUG 68 NEW FRAME : 1452333358.24   <n> l      - turn activity LED on DIG8 on or off
2016-01-09 09:55:58,243 WARNING 68 Discarded RX frame 'non-numerical content' : ['<n>', 'l', '', '', '', '', '', '-', 'turn', 'activity', 'LED', 'on', 'DIG8', 'on', 'or', 'off']
2016-01-09 09:55:58,475 DEBUG 69 NEW FRAME : 1452333358.47 Current configuration:
2016-01-09 09:55:58,478 WARNING 69 Discarded RX frame 'non-numerical content' : ['Current', 'configuration:']
2016-01-09 09:55:58,741 DEBUG RFM2Pi device settings updated: 74 i10 g0 @ 868 MHz  Lock: 1
2016-01-09 09:55:59,233 DEBUG RFM2Pi acknowledged command: > 0y
2016-01-09 09:55:59,563 WARNING Discarded empty frame
2016-01-09 09:55:59,826 DEBUG 70 NEW FRAME : 1452333359.83 Available commands:
2016-01-09 09:55:59,831 WARNING 70 Discarded RX frame 'non-numerical content' : ['Available', 'commands:']
2016-01-09 09:56:00,119 DEBUG 71 NEW FRAME : 1452333360.12   123 x      - Toggle configuration change protection, 1=Unlocked
2016-01-09 09:56:00,122 WARNING 71 Discarded RX frame 'non-numerical content' : ['123', 'x', '', '', '', '', '', '-', 'Toggle', 'configuration', 'change', 'protection,', '1=Unlocked']

We need to know what version of emonhub you are using and if the term "listener " was a slip of the tongue.  Are you running a very old version? Emonhub had "listeners" like oemgateway had when it was first put together, but that changed to interfacers in the very early days. Actually, I think you must have an "[interfacers]" section, because the underscore was dropped from runtime_settings at the same time, and you have "runtimesettings".

To see exactly what version you have, and whether the settings get loaded correctly, use these 2 lines

sudo emonhub service service emonhub restart

tail -f /var/log/emonhub/emonhub.log

By using the "tail" immediately after the "restart", we will get to see the version and each of the interfacers created and the settings applied. let it run until it settles and then ctrl-c to exit. if you attach or cut and paste the log from the restart it should tell us more.

The log you supplied does show emonhub discarding the helptext generated by the rfm2pi, but it doesn't go far enough back to show what triggered it.

Nor does it show any runtime settings being passed and the responses from the rfm2pi.

Paul

Hi Paul, should have said that this is on my fresh re-install, so it's the latest emonhub. And it was  aslip of the tongue - apologies for that. I meant interfacers of course.

Like you slip of the tongue with emonhub service restart  ;-)

In the end I did the following - I wasn't fast enough with 2 commands  in a row!  :-)    The early stuff is just waht was happening before the restart of course.

pi@Homepi-emoncms:~ $ sudo service emonhub restart && tail -f /var/log/emonhub/emonhub.log
2016-01-09 17:51:38,977 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361898.85,10,625,0,0,0,24131,426,500,388,649,495]]&sentat=1452361898
2016-01-09 17:51:39,004 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361898.85,10,625,0,0,0,24131,426,500,388,649,495]]&sentat=1452361899
2016-01-09 17:51:43,981 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361903.83,10,627,0,0,0,24127,426,500,388,649,495]]&sentat=1452361903
2016-01-09 17:51:43,980 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361903.83,10,627,0,0,0,24127,426,500,388,649,495]]&sentat=1452361903
2016-01-09 17:51:48,918 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361908.8,10,627,0,0,0,24126,426,500,388,648,495]]&sentat=1452361908
2016-01-09 17:51:48,988 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361908.8,10,627,0,0,0,24126,426,500,388,648,495]]&sentat=1452361908
2016-01-09 17:51:53,951 INFO emonCMSlocal sending: http://localhost/emoncms/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361913.82,10,626,0,0,0,24130,426,500,388,648,491]]&sentat=1452361913
2016-01-09 17:51:53,992 INFO emonCMS sending: http://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1452361913.82,10,626,0,0,0,24130,426,500,388,648,491]]&sentat=1452361913
2016-01-09 17:51:55,551 INFO Exiting hub...
2016-01-09 17:51:55,596 INFO Exit completed
2016-01-09 17:51:57,724 INFO EmonHub Pre-Release Development Version (rc1.2)
2016-01-09 17:51:57,729 INFO Opening hub...
2016-01-09 17:51:57,734 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2016-01-09 17:51:57,742 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2016-01-09 17:51:57,748 INFO Setting emonCMS url: http://emoncms.org
2016-01-09 17:51:57,752 INFO Setting emonCMS apikey: set
2016-01-09 17:51:57,756 INFO Creating EmonHubEmoncmsReporter 'emonCMSlocal'
2016-01-09 17:51:57,763 INFO Set up reporter 'emonCMSlocal' (buffer: memory | size: 1000)
2016-01-09 17:51:57,768 INFO Setting emonCMSlocal url: http://localhost/emoncms
2016-01-09 17:51:57,772 INFO Setting emonCMSlocal apikey: set
2016-01-09 17:51:57,778 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-01-09 17:51:59,797 INFO RFM2Pi device firmware version & configuration: not available
2016-01-09 17:51:59,805 INFO Setting RFM2Pi frequency: 868 (8b)
2016-01-09 17:52:00,815 INFO Setting RFM2Pi group: 210 (210g)
2016-01-09 17:52:01,820 INFO Setting RFM2Pi quiet: 1 (1q)
2016-01-09 17:52:02,826 INFO Setting RFM2Pi baseid: 10 (10i)
2016-01-09 17:52:04,301 WARNING Discarded empty frame
2016-01-09 17:52:04,532 WARNING 1 Discarded RX frame 'non-numerical content' : ['Available', 'commands:']
2016-01-09 17:52:04,769 WARNING 2 Discarded RX frame 'non-numerical content' : ['123', 'x', '', '', '', '', '', '-', 'Toggle', 'configuration', 'change', 'protection,', '1=Unlocked']
2016-01-09 17:52:05,006 WARNING 3 Discarded RX frame 'non-numerical content' : ['<nn>', 'i', '', '', '', '', '-', 'set', 'node', 'ID', '(standard', 'node', 'ids', 'are', '1..26)']
2016-01-09 17:52:05,582 WARNING 4 Discarded RX frame 'non-numerical content' : ['<nnn>', 'g', '', '', '', '-', 'set', 'network', 'group', '(RFM12', 'only', 'allows', '212,', '0', '=', 'any)']
2016-01-09 17:52:05,841 WARNING 5 Discarded RX frame 'non-numerical content' : ['<n>', 'c', '', '', '', '', '', '-', 'set', 'collect', 'mode', '(advanced,', 'normally', '0)']
2016-01-09 17:52:06,121 WARNING 6 Discarded RX frame 'non-numerical content' : ['...,<nn>', 'a', '-', 'send', 'data', 'packet', 'to', 'node', '<nn>,', 'with', 'ack']
2016-01-09 17:52:06,366 WARNING 7 Discarded RX frame 'non-numerical content' : ['...,<nn>', 's', '-', 'send', 'data', 'packet', 'to', 'node', '<nn>,', 'no', 'ack']
2016-01-09 17:52:06,602 WARNING 8 Discarded RX frame 'non-numerical content' : ['<n>', 'l', '', '', '', '', '', '-', 'turn', 'activity', 'LED', 'on', 'DIG8', 'on', 'or', 'off']
2016-01-09 17:52:06,850 WARNING 9 Discarded RX frame 'non-numerical content' : ['Current', 'configuration:']
2016-01-09 17:52:07,551 WARNING Discarded empty frame
2016-01-09 17:52:07,811 WARNING 10 Discarded RX frame 'non-numerical content' : ['Available', 'commands:']
2016-01-09 17:52:08,060 WARNING 11 Discarded RX frame 'non-numerical content' : ['123', 'x', '', '', '', '', '', '-', 'Toggle', 'configuration', 'change', 'protection,', '1=Unlocked']
2016-01-09 17:52:08,294 WARNING 12 Discarded RX frame 'non-numerical content' : ['<nn>', 'i', '', '', '', '', '-', 'set', 'node', 'ID', '(standard', 'node', 'ids', 'are', '1..26)']

Can we see a bit more log?

The log shows pretty much what I expected to see, the non-numerical content warnings up to "WARNING 9" are fine there are no errors as such, the first helpfile text may be in response to the attempt to read the configuration and firmware version which is done by sending a "v" command and this is not recognized by early rfm12 rfm2pi's, hence the "config and version info unavailable" message, but after the first helptext it appears to start again in the last few lines

2016-01-09 17:52:07,551 WARNING Discarded empty frame
2016-01-09 17:52:07,811 WARNING 10 Discarded RX frame 'non-numerical content' : ['Available', 'commands:']
2016-01-09 17:52:08,060 WARNING 11 Discarded RX frame 'non-numerical content' : ['123', 'x', '', '', '', '', '', '-', 'Toggle', 'configuration', 'change', 'protection,', '1=Unlocked']
2016-01-09 17:52:08,294 WARNING 12 Discarded RX frame 'non-numerical content' : ['<nn>', 'i', '', '', '', '', '-', 'set', 'node', 'ID', '(standard', 'node', 'ids', 'are', '1..26)']

But there isn't enough to be sure the expected responses to the commands 8b, 210g, 1g and 10i aren't going to follow. If you were able to set the group to 210 in minicom, we have no reason to believe emonhub isn't able to do the same, but I cannot see a valid response or enough log to know there was no response.

Paul

Paul,

I have attached 2 files. The first one is a copy of the log from before I used minicom to change the group to 210. You can see the responses from the RFM12 with the command options. These come a couple of times. You can also see emonhub saying it is going to set the group to 210 but that never happens in the RFM12. The proof of this is in the 'G' prefix to the data at the end of the file.

The second file is a fuller version of what I put in the earlier post, so up to and including the point where the system settles. In this case of course the group has already been set to 210 using minicom, so the command to the RFM12 could of course still be being ignored. Although of course now the system works because the RFM12 code doesn't drop in the 'G' prefix.

Simon

Looking at the first log there are 2 "configuration confirmations" and both say the settings are locked, that would prevent emonhub from changing them. I suspect when you changed the group in minicom you unlocked using "123x" before changing the group, there are no configuration confirmations in the second log but I'm guessing you locked the settings again after setting the group, which maybe why there are no responses from the rfm2pi when emonhub sends commands.

This will also explain why emonhub wasn't able to correct the group 0 in the first place. I cannot say why node 0 got set, maybe a glitch in the firmware, but emonhub may have been able to rectify it had the settings not been locked. 

Paul

Hi Paul,

I didn't unlock it, just set the group id with minicom.

Do you mean this line in the 1st log?

2016-01-09 10:05:59,261 DEBUG RFM2Pi device settings updated: 74 i10 g0 @ 868 MHz Lock: 1

Because if you look at the help info on the commands a bit earlier in the file the command for locking/unlocking says that unlocked =1.

So emonhub should be able to make the changes. All a bit odd.....

Simon

I did see the "unlocked = 1" but that didn't make any sense since the "Lock: 1" is not normally seen in normal operation and running correctly ie no message = unlocked, if you didn't unlock it then that undermines that idea anyways.

Are you able to change the group by editing emonhub.conf? can you try and then change it back?

If you watch this is the emonhub.log you should see a response from the rfm2pi.

I'm really not understanding how there could be an issue, the bracketed value at the end of each command in the log is the serial command echo'd via print, it is not hard written text eg "Setting RFM2Pi group: 210 (210g)" means that "210g" was sent to the serial port, it is there for debugging. if it worked from minicom it must work from emonhub.

Is this on a Pi? how old is the rfm2pi? is it possible it's some very early lesser known firmware that I haven't encountered?

Paul

Paul, see attached file with logs and minicom output

Briefly I changed emonhub from 210 and 10 to 200 and 15 and transmissions stopped.

Changing back again didn't restart transmissions. On investigating with minicom, the group was set at 120. At first I thought this was a typo, but emonhub was set to 210.

Using minicom I reset the RFM12Pi to 210 and transmissions restarted.

Thought I'd try just setting the group, so set it to 123. emonhub reports sending the group on restart but it obviously doesn't as transmissions continue and minicom says that the RFM12Pi is set to 210.

All very odd. I now have a functioning system on group 210, node 10 but with emonhub set to 123 and 10....  So somehow the g command isn't getting across.

This is on a Pi of course and the RFM12Pi is one of the old ones with Martin Harizanovs name on as well as openenergymonitor.

Simon

Both the rfm2pi v1 and v2 had Martins name on, is it a "SMT" (surface mounted) ATmega328p or a "DIL" (dual in line through hole" chip? not that it should make any difference if they were fully compatible, buth I have zero experience with the v1 and have never tested or even tried one.

I can see no evidence of any serial commands being confirmed by the rfm2pi in the emonhub logs, but the fact that there are 3 lines logged with bracketed commands means they were sent. these lines from emonhub

self._log.info("Setting " + self.name + " %s: %s" % (key, setting) + " (" + command + ")")
self._ser.write(command)
# Wait a sec between two settings
time.sleep(1)

show how the same variable (eg 210g) get printed in the log and written to the serial port, then a 1 sec wait before the next setting. Your logs show 3 consecutive setting logs each separated by 1 second, without any errors or crashes. 

I do not understand why minicom would be different and can only assume the line endings or serial settings may be slightly different, or there is a permission issue that isn't causing a error.

Also you say the "g" command is ignored and do not mention changing the node id back from 15 to 10 on the rfm2pi can you confirm if it's just the group that isn't being set or all the settings?

Could you also try setting a different group from within emonhub? The attempt to set group 200 resulting in a group of 120 has thrown me. I see no links between the numbers 200 and 120 ( eg bitshifted). If the group did change then would suggest there is an ability to write to the rfm2pi, but the group is read wrong, so why is the quiet or node not being set (even if incorrectly)?

Assuming you installed emonhub with the installer there should be a emonhub user belonging to both the tty and dialout groups.

Is this on "Jessie" ? again I'm unaware of any compatibility issues concerning emonhub but it's still early days and I wouldn't say "Jessie" compatibility is tried and tested enough to be confident with it yet.

As a side note almost definitely unrelated to this issue, the node id's are supposed to be unique on an RFM network, you can use any from 1 to 30, you only have 2 devices they shouldn't both be 10, the OEM standard is to set the rfm2pi as node 15 (baseid).

Paul

Hi Paul,

This is on a my trusty old PiB with a fresh install of Jessie Lite and emoncms and emonhub following the Raspi installation guide. The RFM12Pi is the SMD version. Everything working perfectly since I made the change from group 0 to 210 with minicom, which is where this thread started. 

Couple of side notes - there is only one device on the RFM network sending data, so no confusion over the node ids. And the reason I'm persevering with this is that for me the Pi2 with Jessie and an RFM69 regularly fails, either the 69 stops delivering data or the wifi goes down.

Just for refernce, these are the settings in emonhub.conf

[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 9600
    [[[runtimesettings]]]
        group = 210
        frequency = 868
        baseid = 10

Anyway back to the testing...

I have tried setting baseid to 15, no change in the RFM12, I still keep on receiving data.

Any change to the group likewise, data still keeps on being received.

So for each of these scenarios, the RFM12 settings didn't change, which is odd because earlier today they did change. The logs for these look just the same as the ones I've already shared with you of course.

So this seems to intermittently work, which would suggest some kind of comms failure. Something else that might point to this is the fact that the log shows several instances of the RFM12Pi sending the help text for the commands (which are of course rejected by emonhub as not valid data). So the RFM12Pi is seeing something from emonhub but not anything it can recognise as a command. At least I guess that's what's happening.

Without some kind of protocol analyzer we'll probably never get to the bottom of this. I'm happy the system is working and will rely on minicom if I ever need to make any changes. And I guess we can park this issue until such time as someone else with a similar setup has the same problem. Unless you have some fancy way of intercepting the actual comms between emonhub and the RFM12Pi.

Thanks for persevering with this this far.

Simon

Although it may not be causing any issue the rfm2pi is itself a node, currently you have node 10 (emonTx)  transmitting data that is being received by node 10 (the rfm2pi).

At this point, if it were me I would do 2 things update the firmware in the rfm2pi to ensure I knew what firmware was installed and try installing to "Full Jessie" I have recently been burnt by chasing wifi issues and then path issues in minibian. (you also had some issues with wget I recall)

If you remove just the games and wolfram engine from the full version you get a full working "Jessie" with all the tools and settings we are familiar with. 

You could set up some sort of serial monitor but it's not guaranteed to highlight the issue and you will still be running old firmware of an unknown vintage and an less familiar (unpredictable) OS image.

If it's working you could just run with it until we are more sure of Jessie and how/if it effects emonhub and the serial port. but in the scale of unknowns the full jessie is lower than lite and your rfm2pi firmware, so far ( I have my fingers crossed while i say this) no other users (of full jessie, rfm2pi and v1.2 emonhub) have reported any issues.

Paul

no other users (of full jessie, rfm2pi and v1.2 emonhub) have reported any issues.  Yet!   ;-)  :-)

To be honest, from my reading of the posts about issues with wifi etc. they are all from folks using the SD card image which is based on minbian not Jessie Lite. I have worked all the time from Jessie Lite (apart from one tryout of the SD card image) and although there's no real documentation as to what's not included, I'm guessing it's just minus the games, Wolfram etc. (as you say) and the browser. Not having the browser does make setting up wifi a bit trickier but I have found that a simple two line addition to the wpa_supplicant file gets wifi going straight away.

Minibian must have been chosen for a reason, I'm not going to get into that one, all I know is that Jessie Lite is working fine. (I ought to say - touch wood - of course...)

As for updating the firmware on the RFM12Pi, I'm loathe to do that. That old system of PiB + RFM12Pi has functioned without any hitches for a couple of years and while I may not know exactly which version of firmware is in the RFM, I do know it works. I had originally intended to move everything to a Pi2 with a new RFM69 but this has proved so unreliable that I've given up on it. I have had all sorts of issues with the RFM69 (I put it down to that but it could be somewhere else). The system will just stop recording data and the only way to revive it is to do a reboot and I'm not going to put an auto reboot in every few hours...

As I said I can live with having to change the group and node with minicom if I ever need to. But being back to a stable system, I'm never going to need to do that.

SimonSimon

EDIT The issues with WGET were actually an issue at my ISP with their DNS hijacking the github address for some reason. I worked this out with the help of the raspberry pi forum folks. So no issue with Jessie Lite.

paul, the penny has just dropped for me as well.

You said: Although it may not be causing any issue the rfm2pi is itself a node, currently you have node 10 (emonTx)  transmitting data that is being received by node 10 (the rfm2pi)

I had understood the following

# This interfacer manages the RFM2Pi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer
    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 9600
    [[[runtimesettings]]]
        group = 210
        frequency = 868
        baseid = 10

To mean that the interfacer is looking for data from an attached device g210, f868, nodeid 10.

What your statement says is that my interfacer should have a unique id of it's own. This is new to me. We do need some documentation!   It's obvious when you state it but when you are just using one remote device it isn't clear at all.  At least it wasn't to me. A duh! moment  :-)

Simon

PS At least we know it works even if they do have the same ids...   :-)