WeatherFlow data unavailable to programs

[Bumbershoot]

Hi io_guy,

In an initial attempt to utilize the data provided by the two NodeLink WeatherFlow nodes, I notice that the only data that's available to use in programs is data that is provided to the AC without any labels or formatting. Values that are straight up numeric values, such as: "Lightning Strike Count", "Heartbeat" and "UV" are available to programs, while the rest of the values, all which have labels or some formatting in the AC are not, values such as: "Illuminance" (lux), "Wind Average" (mph), "Humidity" (%).

My use case is to insert these values into variables, among other things, but I can't.

FWIW, there is a difference between the Polyglot WeatherFlow nodeserver and the NodeLink WeatherFlow nodeserver in this regard.  Example: with the Polyglot server, the "Humidity" value is available, while not in the NodeLink nodeserver.  The value for "Wind Direction" appears to be unavailable in either nodeserver.

I hope I'm not missing a trick. 

Thanks for your time and efforts.

EDIT: version 0.9.33.

[io_guy]

I broke them if they're not available.  Will take a look tonight and fix.  

[io_guy]

You sure your node definitions are up to date?

 

[Bumbershoot]

1 hour ago, io_guy said:

You sure your node definitions are up to date?

 

Yes, I have the same node definitions that appear in your screenshot. 

The issue is that the "THEN" stanza of the program below will never update the variable "i.WindAverage" (nor will a program ever evaluate to "TRUE" if one of the data elements is evaluated in the "IF" stanza). 

IrrigationWindAverage - [ID 008C][Parent 0089]

If
        'Devices / dirNodeServers / WeatherFlow / WeatherFlow Sky' Heartbeat is not 0
		//"Heartbeat" is usable in this program, as it has no data label.
 
Then
        $i.WindAverage  = 'Devices / dirNodeServers / WeatherFlow / WeatherFlow Sky' Wind Average 
		//"Wind Average" is not usable in any stanza of this program, as it has a label of "mph".
 
Else
   - No Actions - (To add one, press 'Action')
 

The only values that will insert into variables are the values that don't have a data description/label in the AC ("Heartbeat" and "UV", in the screenshot below).  The values that won't update have data descriptions/labels in the AC (ex., "inches", "mph", "lux", "Volts", etc.). 

I hope this makes some sense.  The data itself is present, and it appears correctly in the AC.  I just can't do anything with it in programs.

I apologize if I'm missing something that should be obvious.

[io_guy]

Sounds like a UDI problem.  I'll send them a note.  

[Chris Jahn]

I'm not sure I understand the problem.  What value does $i.WindAverage get if you run the the Then path of the program?  Just to be clear, you should be able to copy any node status into a variable.

[io_guy]

Chris,

I try to set (in a program) each driver in Air and Sky (about 18 total) into variables.  It's only the drivers NodeLink sends as UOM 25 that actually work.  All others stay as 0.

My screenshots show the Device page fully populated, the program I use to write values, and the Variable list showing most values still at 0.

[Chris Jahn]

This looks like a bug, can you DM the nodeserver files to me (nodedefs, editors, etc.)

[Chris Jahn]

Now I see whats going on here.  It looks like you are correctly specifying the proper UOM for the various status values (e.g. UOM=48 (MPH) for Wind Average), but the editor you have specified for it uses the UOM=25 (Index).  The editor must either use the same UOM as the status value or a compatbile UOM.  A compatible UOM would be something like having the status use Celsius but the editor use Fahrenheit, and thus could be properly converted.

Therefore, the solution is to make sure the UOM's on your editors match the UOM's of the status they are being used for.

[io_guy]

Chris,

I think I must have misunderstood our old email on UOM.  I'm trying to avoid having separate nodedefs for metric vs. US (which I do for my other devices). 

It's easy with temperature as I can just use 14, but there's nothing generic for the other UOMs.  

In my mind if I set UOM 25 in the nodedefs, the ISY should just take it at face value.   

[Chris Jahn]

On 7/13/2019 at 2:22 AM, io_guy said:

Chris,

I think I must have misunderstood our old email on UOM.  I'm trying to avoid having separate nodedefs for metric vs. US (which I do for my other devices). 

It's easy with temperature as I can just use 14, but there's nothing generic for the other UOMs.  

In my mind if I set UOM 25 in the nodedefs, the ISY should just take it at face value.   

Just to be clear, the editor define which UOMs that the value can be converted to when assigning it to a variable.  If the chosen editor UOM matches the status UOM then no conversion is needed (apart from possibly precision), but for example, if the status is 25 Celsius and the variable is to be assigned the status in Fahrenheit (i.e. editor supports Fahrenheit), then the variable will be set to 77 (77F = 25C).

You can have multiple ranges in an editor, they just must have different UOMs.  Therefore, you can have an editor that supports both Celsius and Fahrenheit.

 

[io_guy]

I don't see this happening:

• I set a UOM of 83 (km) and send an 83.  It shows up as 1.2
• I then send the value (converted by NodeLink so now 0.7 miles) as a 116 and it shows in the ISY as 0.7
• The ISY does not convert the profile KM to status Miles, it simply uses the value I sent and just changes the shown units

The conversion only makes sense if the ISY itself had some way of setting overall units for the system.  It doesn't so I'd rather have the Node Server be in control of its own conversion.  My bigger issue is it's a little messy to have two separate NodeDefs for the same device.  If a user changes his Ecobee thermostat units from C to F they (or the Node Server) now need to replace the ISY nodedef files and hope all their programs aren't broken.

[Chris Jahn]

Yes, the status you send to the ISY will always show whatever UOM you gave it.  In programs though, you will notice that when assigning a status to a variable it shows and uses the UOM defined by the editor.  If the editor supports more than one UOM, you can select the UOM to use.  This way you always know what UOM the value in your variable will be.

Generally its better for the customer to choose a nodedef that matches what they need (e.g. C vs F) and stick with it.  Alternatively, you can also have a single editor that supports both C/F so they don't have to change nodedefs.

[io_guy]

@Bumbershoot

I think I have this sorted out.  This device started using a few different functions in my Node Server which I haven't done before.

I'll cut a new version soon that should get your programs fixed.  However, make sure that the units you choose in NodeLink are the units you use in the ISY programs.  When you make your ISY program you'll see a choice between KM/Mile, for example, for distance.  If NodeLink is "US", choose "Mile" or it won't work.  That portion is a bug in the ISY that will be fixed in a later version (conversions between different UOMs).

[Bumbershoot]

10 hours ago, io_guy said:

When you make your ISY program you'll see a choice between KM/Mile, for example, for distance.

This should be easy enough to sort out.  Thanks for your work and persistence with this.

[Bumbershoot]

In limited testing this morning, the problem appears to be fixed. 

On 7/15/2019 at 5:48 PM, io_guy said:

When you make your ISY program you'll see a choice between KM/Mile, for example, for distance.  If NodeLink is "US", choose "Mile" or it won't work. 

This seems to work as intended.  Thanks again for your efforts here.