Shows the correct station in ISY and the three sensors but no data. 

ERROR station:Query: Parsing failed: string indices must be integers

Thoughts?

AmbientWeather_6-1-2022_103856_AM.zip

Edited June 1, 20223 yr by pjjameso

Booted Polyglot a couple of time and is now pulling in data.  However the values for Main and indoor are exactly the same. Would think Main would be for outdoor readings?

This station is a WS 5000, in case that matters...

 

AmbientWeather_6-1-2022_105540_AM.zip

Edited June 1, 20223 yr by pjjameso

39 minutes ago, pjjameso said:

Shows the correct station in ISY and the three sensors but no data. 

ERROR station:Query: Parsing failed: string indices must be integers

Most likely it is because the query to Ambient Weather returned an error instead of data (or no data). They aren't known for their reliability.

31 minutes ago, pjjameso said:

Booted Polyglot a couple of time and is now pulling in data.  However the values for Main and indoor are exactly the same. Would think Main would be for outdoor readings?

This station is a WS 5000, in case that matters...

It looks like the AC hasn't read the profile files.  If it hasn't read the profile files, it doesn't know how to layout the data so it uses whatever the last node viewed's layout.  The main layout should have a lot more values.  Restarting the AC will cause it to re-read the profile files.  If that doesn't help, re-send the profile files using the Upload Profile button on the PG3 node details page and then restart the AC again after that.

Bob,

I have pressed the load profile button but that doesnt seem to do much. I can see correct values in the nodes in in Polyglot and have attached a screenshot. Have tried deleting node, rebooting both polisy and polyglot.  Even tried adding the nodes manually in ISY but that doesnt seem to work either.

Thoughts?

The "Load Profile" button won't give any visual indication that it's doing anything.  It simply re-sends the profile files to the ISY.  You can view the PG3 and verify that it really did upload them.  If there are errors uploading the profile files, then that's the problem. 

If the admin console isn't showing the same values as what you posted above, it's because the admin console doesn't have the updated node definitions.   It only reads those files from the ISY when it starts.  So you must restart the admin console before it can show the correct values.

If you deleted the node from the ISY, you'll have to restart the node server so it can re-create the node.

Deleted nodes in ISY, uninstalled AW, reinstall AW in another slot, restarted AC multiple times and Polyglot shows correct values under 'main' node, yet ISY only repeats the indoor values for the main values.

I see the correct values in the AC event viewer. Any thing else i can try to sort this out? Perhaps a bug in this version of ISY?

AmbientWeather_6-1-2022_31814_PM.zip

Edited June 1, 20223 yr by pjjameso

Ok, I found the problem.

You're the first to have a station with a lightning sensor and the lightning batter value was getting parsed as a second main battery causing the main node definition to invalid.

I pushed out version 2.0.6 to the store, if you refresh the store and then restart the node server it should now parse the data correctly.  You'll also have to restart the admin console after the node server starts to get the updated node definition.

 

Bob, you are a genius, its working!  One question, shows battery levels are low on all sensors which I know is incorrect as I just inserted a new battery in number "two".  Any ideas?

The battery information that Ambient reports is binary, 0 or 1.  Currently 0 = OK and 1 = Low.  Seems backwards, so maybe it is.  I don't know where I got that info.

I just checked the api documents and now I'm even more confused

battout - Outdoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
battin - Indoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt1...batt10 - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt_25 - PM2.5 Air Quality Sensor Battery indication, OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt_lightning - Lightning Detector Battery - 1=Low 0=OK
batleak1...batleak4 - Leak Detector Battery - 1=Low 0=OK
battsm1...battsm4 - Soil Moisture Battery - 1=OK, 0=Low
batt_co2 - CO2 battery - 1=OK, 0=Low
batt_cellgateway - Cellular Gateway - 1=OK, 0=Low

Who in their right mind would do this????

12 hours ago, bpwwer said:

The battery information that Ambient reports is binary, 0 or 1.  Currently 0 = OK and 1 = Low.  Seems backwards, so maybe it is.  I don't know where I got that info.

I just checked the api documents and now I'm even more confused

battout - Outdoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
battin - Indoor Battery - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt1...batt10 - OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt_25 - PM2.5 Air Quality Sensor Battery indication, OK/Low indication, Int, 1=OK, 0=Low (Meteobridge Users 1=Low, 0=OK)
batt_lightning - Lightning Detector Battery - 1=Low 0=OK
batleak1...batleak4 - Leak Detector Battery - 1=Low 0=OK
battsm1...battsm4 - Soil Moisture Battery - 1=OK, 0=Low
batt_co2 - CO2 battery - 1=OK, 0=Low
batt_cellgateway - Cellular Gateway - 1=OK, 0=Low

Who in their right mind would do this????

The nomenclature must match the positive logic and then anything is possible and good.. Many times people label things with generic labels...like "BattStat" which does not indicate either state as logic True.

I understand that the label isn't indicating state.  If you look at the different sensor's battery reporting, for some sensors 0 means good but for other sensors 0 means low.

You'd think that "0" would mean the same thing for all sensor battery reports.  Even if the sensor hardware is different, the API should correct that and make it consistent.  I guess we should be thankful that they always use 0/1 and don't have some sensors that report the actual battery voltage.

It's going to take a lot more work to replace the generic parser code that says if sensor has a battery field, create a node value for it.  To having to actually look at what type of sensor the battery field is form and map that to the correct battery logic for that sensor.

 

Sounds like I need to contact AW to correct their API?

Based on my past experience with Ambient I don't think they care.  Their API is already a mess and this is just one problem with it.

I'll have to make a bunch of changes to make the battery values correct for all the different sensors.  With everything else I'm working on, I'm not sure when I'll get around to it.

Thanks Bob, not a high priority for me.