Air hub_rssi reports zero (edited: was 'Sky')

(edited - had hub/air reversed. This matches the output below)

In poking around the data, I see that the obs_air hub_rssi is always zero, yet the obs_sky hub_rssi value seems reasonable (I think).

  • hub status RSSI = -37 (sits 3 feet below the access point)
  • sky device_status rssi = -62
  • sky device_status hub_rssi = -60
  • air device_status hub_rssi = -46
  • air device_status rssi = 0

What is ‘hub_rssi’ as opposed to ‘rssi’ in the air+sky status ?

The air is about 15’ line of sight through a window to the hub, and the sky is perhaps 100’ through walls, the refrigerator, etc. to the hub at the far corner of the house from where the sky is mounted. Stuff is stable regardless, FWIW.

Either there is a BUG or you are getting an excellent signal. I do find that difficult to believe. It seems to me it should be the same as the Air.

How close is the Hub to the Wi-Fi access point?

What is the firmware version on the Sky?

Here goes…

  • air firmware_revision is 20
  • sky firmware_revision is 43
  • hub firmware_revision is 91

I also notice the mqtt_stats moving in the last couple days, now up to 50 (was just a couple/few previously) but I know that’s a futures thing anyway. Just mentioning it in unlikely case there’s something relevant there.

Here’s what I get for the status listening on UDP:

  "debug": 0,
  "firmware_revision": 20,
  "hub_rssi": 0,
  "hub_sn": "HB-00010412",
  "rssi": -46,
  "sensor_status": 4,
  "serial_number": "AR-00013349",
  "timestamp": 1535745239,
  "type": "device_status",
  "uptime": 935803,
  "voltage": 3.49

and for the hub…

  "firmware_revision": "91",
  "fs": "1,0",
  "mqtt_stats": [
  "radio_stats": [
  "reset_flags": "BOR,PIN,POR",
  "rssi": -36,
  "seq": 25918,
  "serial_number": "HB-00010412",
  "timestamp": 1535745242,
  "type": "hub_status",
  "uptime": 259228

and for the sky

  "debug": 0,
  "firmware_revision": 43,
  "hub_rssi": -60,
  "hub_sn": "HB-00010412",
  "rssi": -61,
  "sensor_status": 0,
  "serial_number": "SK-00013695",
  "timestamp": 1535745612,
  "type": "device_status",
  "uptime": 936124,
  "voltage": 3.44

(Edited the original post - I had air+sky reversed in the original problem description…sorry…)

This is something @dsj will need to comment on. Except for the high MQTT, which may be a hint, I don’t see why the hub_rssi is zero.

  • hub status RSSI = Hub to WiFi RSSI (as measured by the Hub)
  • sky device_status rssi = SKY to Hub RSSI (as measured by the SKY)
  • sky device_status hub_rssi = Hub to SKY RSSI (as measured by the Hub)
  • air device_status hub_rssi = Hub to AIR RSSI (as measured by the Hub)
  • air device_status rssi = AIR to Hub RSSI (as measured by the AIR)

The current AIR firmware doesn’t measure RSSI so it is 0 for everyone (I think?). It should probably be NULL or N/A… The only reason there are two values in there is because it was easy to add and we thought it might help troubleshooting. As it turns out, it’s not very helpful: the RSSI values as measured from each side are always very close to each other.


Something seems wrong here.

For hub_rssi I am seeing 0 (zero) from the Air.

If the Air does no measure RSSI then it should be:

  • air device_status rssi = Hub to AIR RSSI (as measured by the Hub)
  • air device_status hub_rssi = AIR to Hub RSSI (as measured by the AIR)

May be please get clarification which is correct?


The bullet points above are correct. It’s confusing, though. The “rssi” value in the device_status messages is the value as measured by the end device. That value has always been there. The newer “hub_rssi” is the value as measured by the Hub, and that’s what the AIR firmware does not support. Even though that value is measured by the Hub, it’s actually passed through the AIR (which was necessary for backward compatibility - I said it was confusing!).

But, as mentioned, you really only need one value. We added the second value it when it looked like some weirdness was going on, but the RSSI values are statistically identical regardless of which side they are measured from. In practice, you can simply ignore the “hub_rssi” value.


That’s what I was missing. That is weird but at least it’s understandable. And it sounds like something I’d do.

Thank you.