Lost an hour trying to debug this on the Virtual plugin ; until I asked myself if the AC did this....

@bmercier, the precision on display seems to be different between the entry number and the actual in Current versus Set Current:

for some reason Set Current in the Eisy-ui is one tenth.  Whats interesting, is the number you enter goes in properly but then shows as one tenth down below:

correct in AC:

 

Not in eisy-ui:

@sjenkins, I'm not familiar with the VirtualPlugin. Please let me know how you configured the Virtual plugin so I can reproduce it.

 

5 hours ago, bmercier said:

@sjenkins, I'm not familiar with the VirtualPlugin. Please let me know how you configured the Virtual plugin so I can reproduce it.

 

Its for Virtual devices ; just called 'virtual' in the plugin store.  I have been re-writing it as I took over curation of it a bit ago; the behaviour exhibits in both the old production and re-written non-production (you will likely find the re-write much easier to read).  The issue shows itself in the temperature devices.

If you install it & configure with one device:

key   value

10    temperature

 

As far as 'configuring' this behaviour, you can see in the profile files there is very little ability to configure beyond a precision variable.  Perhaps eisy-ui is ignoring that?

 

 

Edited September 22Sep 22 by sjenkins

@sjenkins thanks for reporting this. It will be fixed in the next release.

The problem seems to happen when the precision on the editor is different than the precision on the value.

In this case, although the precision on the ST prop is also 1, I think the plugin is setting values with a precision of 0.

19 minutes ago, bmercier said:

@sjenkins thanks for reporting this. It will be fixed in the next release.

The problem seems to happen when the precision on the editor is different than the precision on the value.

In this case, although the precision on the ST prop is also 1, I think the plugin is setting values with a precision of 0.

Thanks @bmercier,

seeking to understand:

so right now when I setDriver(GV0, value), I don't expressly set uom, like:

setDriver(GV0, value, uom=#[name I used in EDITORS])

is that what you are thinking? or is it that value is possibly an int() rather than a float()

This is part of the api which is rather quiet, as well when to use force=True or not.

appreciate your time

21 hours ago, sjenkins said:

Thanks @bmercier,

seeking to understand:

so right now when I setDriver(GV0, value), I don't expressly set uom, like:

setDriver(GV0, value, uom=#[name I used in EDITORS])

is that what you are thinking? or is it that value is possibly an int() rather than a float()

This is part of the api which is rather quiet, as well when to use force=True or not.

appreciate your time

Actually, I'm not fully sure.

What I know is that both the property and the parameter on the command has a precision of 1, but the precision on the updated value from the subscription has a precision of 0.

So I'm thinking that if the value sent is an integer, then precision would be 0 instead of 1.

I don't think there's any work-around for you, except maybe try with a float with something like .01 (which should be rounded to .0), giving the same result as an integer.