I did try to search for this, and came up with nothing. Hopefully this
I am recording data from multiple imps and need to tell them apart. My first thought is to use the MAC address as a header in the data array.
Using the imp.getmacaddress server.log returns (function : 0x8049d2d). This seems to have no relationship to the printed mac address of the IMP-001 which is 0C2A69003E1E. While the WIFI router shows the connected mac address as 0C:2A:69:00:42:6C which is similar to the printed MAC address but not exactly the same.
I just need to tell the data apart. So if getmacaddress is different and specific for each IMP, I am good.
Can anyone confirm this?
The 0C:2A:69 prefix is Electric Imp, and the last three octets are specific to the card - so I think you must have two different imps there.
imp.getmacaddress is a method, so you need to add parentheses to the end to call it, like so:
There’s a catch, though - the MAC address is unique to the imp card, not the board that it’s plugged into. So if you swap the cards, the data will be swapped too. What you probably want to do is use
instead to get the device ID (which is unique to the breakout board or device that has the imp socket in it)
@Hyperone - It sounds like you are calling this:
When you should be calling (as Gino pointed out):
The first example prints the pointer to the imp.getmacaddress function (which is not particularly useful in this case)
The second example prints the return of the imp.getmacaddress function (which is the imp’s mac address).
Its always something dumb. Yes, I was missing the () in the string builder duh.
I’m still not sure why the mac address is not showing correctly in the wifi router connection list. I have run other imps here, so I agree it must be another one. I’m going to write that off as a router issue. At some point today i will reset that router and see if it starts reporting correctly.
Thanks for the help!
I figured out the incoherent router mac addresses: I am disconnecting the 0C2A69003E1E for power saving, so the Router doesn’t show it in the connected list; because it is normally not connected!
The 0C:2A:69:00:42:6C device is running another applicaiton and is connected full-time; which I forgot about
So as usual, it was something dumb!