What just happened to the UDP broadcasts in Hub Fw 134?

So, I was tinkering with parsing the UDP broadcasts from the Hub and all of a sudden the packet broadcasts stopped. My last captured log from this morning (when it was working) shows the Hub had Fw 126. The Hub now apparently just updated and is now indicating Fw 134 and the broadcasts are gone.

The hub shows a steady green indicator and seems to otherwise providing data to the cloud as the Android app seems to be getting live data.

Both Wireshark and my ESP32 project aren’t logging any UDP broadcasts now. Where can I reenable it? (or am I doing something really stupid ?)

That is strange, my RPi running Archives is still seeing the UDP packets fine and it has been through several firmware updates with no changes needed.

Did you figure this out? My code to parse UDP data is crashing on the Tempest, but it’s still seeing the broadcasts…

Is the hub_status packet format change in Hub v143 (documented in changelog) causing your problems?

https://weatherflow.github.io/SmartWeather/api/udp/v143/

@wpns Interestingly, the next morning, my Hub reverted back to fw 126, and the UDP broadcasts resumed. It has been sending out UDP ever sense then, however it seems weird that obs_st type packets are not sent at regular intervals, sometimes over 5 minutes between them. I guess the developer monitors this list and found an “oops” in fw 134 and reverted the update? My hub appears to still be on fw 127 right now.

If you are parsing the Hub status type, here is some Arduino code that should work:

#include <ArduinoJson.h>

const size_t capacity = JSON_ARRAY_SIZE(2) + 2*JSON_ARRAY_SIZE(4) + JSON_OBJECT_SIZE(11) + 160;

DynamicJsonDocument doc(capacity);

const char* json = “{“serial_number”:“HB-000xxxxx”,“type”:“hub_status”,“firmware_revision”:“126”,“uptime”:54024,“rssi”:-66,“timestamp”:1593955959,“reset_flags”:“BOR,PIN,POR”,“seq”:5396,“fs”:[1,0,15675411,524288],“radio_stats”:[22,1,0,3],“mqtt_stats”:[27,0]}”;

deserializeJson(doc, json);

const char* serial_number = doc[“serial_number”]; // “HB-000xxxxx”
const char* type = doc[“type”]; // “hub_status”
const char* firmware_revision = doc[“firmware_revision”]; // “126”
long uptime = doc[“uptime”]; // 54024
int rssi = doc[“rssi”]; // -66
long timestamp = doc[“timestamp”]; // 1593955959
const char* reset_flags = doc[“reset_flags”]; // “BOR,PIN,POR”
int seq = doc[“seq”]; // 5396

JsonArray fs = doc[“fs”];
int fs_0 = fs[0]; // 1
int fs_1 = fs[1]; // 0
long fs_2 = fs[2]; // 15675411
long fs_3 = fs[3]; // 524288

JsonArray radio_stats = doc[“radio_stats”];
int radio_stats_0 = radio_stats[0]; // 22
int radio_stats_1 = radio_stats[1]; // 1
int radio_stats_2 = radio_stats[2]; // 0
int radio_stats_3 = radio_stats[3]; // 3

int mqtt_stats_0 = doc[“mqtt_stats”][0]; // 27
int mqtt_stats_1 = doc[“mqtt_stats”][1]; // 0

Not really, though that was a good thought. Looks like Redis was having a problem so I did:
RedisDB.set(RedisKey,json.dumps(wx_dict[wx_key]),ex=RedisKeyExpire)
adding json.dumps() seems to have sorted it out.

Can you share your station ID

upgrades are done automatically and not one by one, and the team is off for this long week end except those on watch. FW 127 was never a stable release to begin. If you were on 126 it might that you migrated to 143 as that one was rolled out partially but for sure no going back.

2 Likes

@eric The station ID is 22878

Here are the two status packets from a couple hours ago. I don’t have a capture file from the time it was on 134. Well, somehow it got rolled back! Certainly it isn’t in our power to do so :slight_smile:

{“serial_number”:“HB-000xxxxx”,“type”:“hub_status”,“firmware_revision”:“126”,“uptime”:54024,“rssi”:-66,“timestamp”:1593955959,“reset_flags”:“BOR,PIN,POR”,“seq”:5396,“fs”:[1,0,15675411,524288],“radio_stats”:[22,1,0,3],“mqtt_stats”:[27,0]}

{“serial_number”:“ST-000xxxxx”,“type”:“device_status”,“hub_sn”:“HB-000xxxxx”,“timestamp”:1593956081,“uptime”:507656,“voltage”:2.54,“firmware_revision”:129,“rssi”:-73,“hub_rssi”:-73,“sensor_status”:0,“debug”:0}

There is no need to xxxx out the serial numbers. They aren’t secret.

you have one station fully offline and the one you mention has hub FW134 and Tempest FW129 which is perfectly normal (some have migrated to hub FW143 and yours will at some point soon)

Not sure where you get the first return from that mentions 126, sure you’re looking your hub and not someone else’s ?

1 Like

@GaryFunk. Just a habit I have.

@eric , Yes, I have two hubs and two Tempests… Only one is online. I intend to relocate it elsewhere.

I’ll grab some fresh data from my local network. I can’t see how I’d be looking at someone else’s as UDP broadcasts on my own network. Where are you getting 134 from?

Status packets -

{“serial_number”:“HB-00030829”,“type”:“hub_status”,“firmware_revision”:“126”,“uptime”:72997,“rssi”:-72,“timestamp”:1593974932,“reset_flags”:“BOR,PIN,POR”,“seq”:7292,“fs”:[1,0,15675411,524288],“radio_stats”:[22,1,0,3],“mqtt_stats”:[35,0]}

{“serial_number”:“ST-00014701”,“type”:“device_status”,“hub_sn”:“HB-00030829”,“timestamp”:1593974980,“uptime”:526556,“voltage”:2.55,“firmware_revision”:129,“rssi”:-71,“hub_rssi”:-71,“sensor_status”:0,“debug”:0}

Wireshark capture of same

I have some access to back office, this is your active station

Nice! So, why does the UDP data not reflect 134 anywhere? I only see firmware_revision 129 in the json.

Also, is there a way to add other hubs into the application? I bought 4 units actually, and two of which are associated at different locations (and different accounts). When I tried to add my station into one of the other instances of the iOS app, it knocked me off of my own.

Only way I see to handle this is to add all four under the same account, and share the credential?

There is only one instance of the application.

Ok, so that was not a good word to use. I’m not trying to launch the app twice. To put it differently, can a hub be associated to more than one account? When I say had hub #1 associated to my account on my Android phone, then tried adding that #1 hub to a different phone which is logged in on a different account and having hub #2 already associated on it-- my cell lost connectivity with hub #1. The app let me do it without warning me that hub #1 was already associated to a different account and just let me proceed.

No. A Station is assigned to a single account. An account may have several stations.