Multi box operation 'Instancing'
25 February, 2014 - 11:06
I've decided to have a go at running both my boxes simultaneously on my network to allow me to fiddle with one while letting the other run the heating without causing grief.
I've set the second box with the hostname 'deadbox' and allocated a static ip and changed the mac of eth0 and eth1 on the management page. On the instance page I've changed the UID's of twitter, livebox and plugboard from 00XX to 11XX. I had expected the UID of xap messages from the second box to change to 11XX but this doesn't seem to have happened.
I'm not really sure what to put in the 'HAH Device' box on the instance page, I did try a number but it was just removed when I saved the settings.
The boxes seem to be cohabiting reasonably steadily at the moment is there anything else that I need to do?
26 February, 2014 - 15:29
#3
xAP UIDs should be unique
Please do keep UIDs unique, whether or not it's a good thing it is required for the xAP specification adherence. If you don't then the world won't end , you'll likely get away with it in smaller xAP networks but it may cause you lots of difficult to resolve issues later on.
It is unfortunate that the HAH UID can't be derived from the LiveBox MAC address (as they themselves can be duplicates). They couldn't really be auto generated from the IP address either as that creates other issues when using DHCP. A hash of the host /source name is a possibility.
Several xAP programs and devices , including xAPFlash in some aspects, recognise xAP devices by their UID rather than their source address. Sometimes this was done because of memory constraints, sometimes for speed and sometimes just because it was easier / laziness. Also some early iServers implemented UID rather than source address filters.
Storing UID's is far more memory efficient than source addresses and in limited memory resource processors holding a lot of endpoints this might be the only possible solution. The xAP specification does not limit the length of a source address. Also when adding xAP support into an existing non xAP controller the device identifiers might not be flexible enough (e.g. numeric only) to hold source addresses, HomeVision being such an example as it has a 16 character restriction.
If you have duplicate UID's then these controllers can't tell your devices apart and will react to both regardless that the source addresses differ. However both will not be controlled as you can only target by source address and not by UID. Hence any device that needs to control another must either store it's source addresses or be able to recover it from a UID - which is achievable if the device uses the BSC schema but awkward otherwise.
K
Alan,
The 'HAH Device' field can be left empty this is something left over from when the xAP addresses where not using the hostname.
It can still be used in the situation whereby you migrate your ENTIRE livebox system to another host but you don't want to call that host "livebox" this field allows you to overrride the hostname that is normally used - Multiple HAH systems are much easier if the hostname is used.
Changing the MAC address for your bridge NIC's is good, you don't want collisions.
As for the UID's most things on the network don't really care about colliding UID'd I know most of HAH stuff doesn't care.
The UID field was a point of contention with the xPL fork and it was dropped. I kind of get why its a good idea for small PIC/AVR devices but the source address is already unique and most small micro's can parse the large xAP payloads these days anyway.
Having said they you're change should have stuck. I'll look to see if this is a regression.
UPDATE: Yup a regression from 311-> 312 - I guess you can't change that much code and get away with it !
Let me know if this is causing a problem and I'll push a 313. There will also be a fix for bscmsg.
Brett