HI

There seems to be a bug if we define more than 1 uom per editor

In the AC we can select the type - e.g. index or unix time

but in the eisy-ui you cannot pick a,d it select the index - even wif the value is programmed as unix time

Strangely enough - if I use AC to create the program it shows unixtime, but I cannot select in the eisy-ui

First line was created by AC - second by eisy-ui

Uom selection is in the value dropdown.

This is a status? If I recall status can only have a single UOM, this may be a bug in the Admin Console

it is a variable assignment - status - I am allowed to have 2 or more definitions for an editor - you just forcetype when you setDriver

AC has a specific selection of the type (after you select TIME) - you can argue TIME (=Last Device Update) should really show the text and not the variable name (like the AC)

Edited October 6Oct 6 by Panda88

I've never seen multiple UOMs used for status, even the thermostat definitions are dynamic. Looked into firmware and there are even some conversions, although none for time. Some Values are silently dropped if the UOM does not match others populate the raw value. So cannot guarantee any outcomes when the program is run.

Submitted pull ID: /eisy-ui/pull/101. Also fixed formatted value for Properties.

OK - sounds like I have to redo most of my plugins as I have been using this extensively - it is difficult to report a value if there is no valid data retrieved? but I can see it causes issues in programs if uom changes

it is interesting that your window shows Property and Uom where mine does not - maybe you are at different version

It is also interesting that uom25 seems to be preferred in the list - it says Index, .... - My use uom25 is a backup for when stuff does not work

Anyway, it looks like it is not good to combine numeric vales and non-numeric values in an editor

..it was just fixed and pushed, maybe next release. Uom 25 would silently drop instead of populate a variable if the value was set for a time/date uom, which is likely a good thing.

There is nothing wrong with your approach, I was unaware it was implemented and we may need to publish the behavior. eisy-ui program edits were based on UD Mobile programs which all assumed there could only be a single UOM for Properties. Based on this assumption it is very possible there are other errors in eisy-ui if a prop has multiple editor ranges (UOMs).

After thinking about this more, the combo opens up many possibilities, likley what you were trying to implement. A property could have a percentage (UOM 51) or error (index 25) without needing to define an extra prop.

I just need to figure out how to implement this in charts

great

yes - this is the use model

Note, some nodes may have different units supported (like F vs. C or L vs Gal), but I am personally moving away from this using dynamic profiles

5 minutes ago, Panda88 said:

great

yes - this is the use model

Note, some nodes may have different units supported (like F vs. C or L vs Gal), but I am personally moving away from this using dynamic profiles

I think your approach is fine using dynamic profiles, eisy-ui/charts need to change.

Attached investigation of existing conversions, likely needs future improvements in firmware like time.

uom-conversions.md