search

heatseeknyc / relay

web app for setting up sensors, receiving and storing their data, and viewing it
0 stars 2 forks source link

some hubs register themselves with wrong xbee id #3

Closed williamcodes closed 8 years ago

williamcodes commented 8 years ago

Hub FD47 (0013A20040d847dc) never appears registered, even once connected. I verified that the physical id for the xbee on the pi corresponds to the appropriate short code according to the canonical spreadsheet. Instead, it appears as E971 (0013a20040e00020). I brought a cell within range and it did in fact appear immediately. I then powered off hub FD47 and the relay showed hub E971 go offline.

williamcodes commented 8 years ago

Hub 8931 (0013A20040D847DE) exhibits the same behavior as FD47. It appears as E971 despite having a correctly short coded xbee. I again brought a cell within range and it connected just as with FD47. I unplugged the hub, and E971 went offline.

williamcodes commented 8 years ago

Hub C11C (0013a20040d8480d) was mimicking 5F35 much the way the others were mimicking E971. I restarted several times, to no avail. Then I SSHed in via the port assigned allegedly to 5F35, and did the following:

python3 -m hub.request_xbee_id
python3 -m hub.get_xbee_id

It returned the correct xbee id. I restarted and it registered correctly. Perhaps we should add something to the startup script that forces it to check its xbee id. I thought that happened on startup already but it seems like it isn't. Or if it is, it isn't having the desired effect so maybe we need to do it later in the process?

williamcodes commented 8 years ago

This technique worked on both FD47 and 8931. I just requested the xbee id, I didn't bother using the get method afterwards, which had the same effect as expected.

hrldcpr commented 8 years ago

This isn't really related to the relay server, so 'moving' it to heatseeknyc/firmware#5.