Query HUB for attached Devices

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.

Thoughts?
–Sam

4 Likes

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.

5 Likes

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…

:smiley:

3 Likes

At most you only have to wait 61 seconds.

3 Likes

:+1:
Agreed. Guess, I just want things to be handed to me on a silver platter… :wink:

2 Likes

You and me. Let’s start an exclusive club. :wink:

3 Likes

I’ve given this a lot of thought.

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.

1 Like

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.

1 Like

From what I am able to tell is you connect to the Hub(s) I range. The API will handle the rest.

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.

2 Likes

While you’re making new status messages… :wink:

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.”

5 Likes

I believe Buckaroo Bonzai summed up Raytheon’s statement:

“No matter where you go, there you are.”

5 Likes

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

2 Likes

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?

3 Likes

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)…

5 Likes

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.)

4 Likes

I understand. You use the term sleep differently than I was taught.

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. :sunny:

5 Likes

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. :stuck_out_tongue_winking_eye:

6 Likes