Via the UDP API, it would be beneficial to be able to query the HUB for what devices are attached… or have the HUB send out a UDP ‘devices’ packet that lists the attached devices.
I am working on a way to auto-detect multiple HUBs and multiple attached devices… so my Wx Console can be more intelligent, and show relevant data in an intuitive fashion.
When you receive a UDP packet with type of “hub_status” the “serial_number” tells you which hub is it.
Then when you receive a packet with any other type 'hub_sn" tells you which Hub it belongs to and the “serial_number” tells you the device and type. I use this data to build my internal configuration.
Yeah, that’s what I am working on now… Just thinking a single packet containing that data would be more efficient than waiting for x minutes for each data packet…
The Hub doesn’t have an API for UDP so that’s out. Maybe the Bluetooth API will offer something. It’s easy enough to add Bluetooth to a Pi and some other devices. That may give us what we want.
I’m not sure the Bluetooth way is right… then you have to connect to each BT device to see if it is an SWS…then query.
Waiting for the UDP broadcasts appears to be the best way right now. Maybe WF will take the ‘devices’ HUB broadcast into account for v40 of the UDP spec.
Adding a “connected devices” to the hub_status message is not a bad idea. However, keep in mind that it would only be a best guess, because the device connections are not continuous. The AIR, for example, wakes up every minute, connects, then goes back to sleep. During that minute, the Hub doesn’t know if any particular devices is still there. It only knows it was there last time it connected.
That reminds me of the Raytheon manual on missile guidance.
“The missile knows where it is at all times. It knows this because it knows where it isn’t. By subtracting where it is from where it isn’t, or where it isn’t from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the missile from a position where it is to a position where it isn’t, and arriving at a position where it wasn’t, it now is. Consequently, the position where it is, is now the position that it wasn’t, and it follows that the position that it was, is now the position that it isn’t.”
It would be OK if the connected_devices field was not 100% accurate… it would at least give a starting point for determining what devices are out there.
–Sam
Let me ask about this. Does the entire Air go to sleep or just the radio? If it’s the entire Air, how does it detect lightning? Does it wake up if lightning strikes 30 seconds after it went to sleep?
The Franklin chip has an IRQ function on pin #10, and I’m sure that it can be wired to wake just about anything short of Rip Van Winkle (a local story here)…
What @vreihen said: the lightning sensor wakes it up when necessary. It’s probably more accurate to say the AIR is normally in a state of deep sleep, but it can be awakened instantly by various interrupts (a timer, the lightning sensor, the button, etc.)
Does the Hub know which devices are allowed to communicate with it? If yes, does it know the serial number of each device?
We are slowly accumulating information about the Station and gaining better understanding how this marvelous unit works. This is good for us but seemingly bad for you as we ask for more and more.
Well Gary . . . Apparently you think that @dsj is a technical guy, but he is actually a landscape maintenance guy and his main job is to keep the application hedges neatly pruned and trimmed so they are pretty and presentable.