openhab / org.openhab.binding.zwave

openHAB binding for Z-Wave
Eclipse Public License 2.0
171 stars 206 forks source link

[feature request] Add UoM for sensor_luminance #1394

Open 5iver opened 4 years ago

5iver commented 4 years ago

I just noticed a bunch of errors in my openhab.log...

2020-08-27 11:45:21.791 [DEBUG] [org.eclipse.smarthome.core.library.types.QuantityType] - Unable to convert unit from % to lx

... that were caused by incorrectly creating Number:Illuminance Items for some new Z-Wave lux sensors with sensor_luminance Channels. Was #978 to implement this?

bodiroga commented 4 years ago

Hi @openhab-5iver!

Did you create the item manually or from Paper UI? Can you show us the definition of the item?

I'm not sure if they are related, but I would say that there is an error here: https://github.com/openhab/org.openhab.binding.zwave/blob/2.5.x/src/main/resources/ESH-INF/thing/channels.xml#L1053

The channel type should be:

<!-- Luminance Channel -->
    <channel-type id="sensor_luminance">
        <item-type>Number:Illuminance</item-type>
        <label>Luminance</label>
        <description>Indicates the current light reading</description>
        <category></category>
        <state pattern="%.1f %unit%" readOnly="true">
        </state>
    </channel-type>

@cdjackson, do you want me to create a PR to address it?

[EDIT: In general, we should review the whole UoM state of the binding, as lot's of channels should be changed. But that is a breaking change, so we should do it for OH3 :wink: ]

5iver commented 4 years ago

Did you create the item manually or from Paper UI? Can you show us the definition of the item?

I created unmanaged Items. Here is an example of what did not work...

Number:Illuminance                  Outside_Driveway_Motion_Luminance           "Motion: Driveway [%.0f lx]"                                   <sun>            (gOutside,gLuminance_Sensor)                 {channel="zwave:device:55555:node5:sensor_luminance"}

As I pasted that, I remembered that this device specifically does not report lux or solar radiation, but some number that the manufacturer made up. I still think this should be implemented in the Z-Wave binding, but users will need to understand that some devices do not report standardized values.

I'm not sure if they are related, but I would say that there is an error here

I concur, but have no idea if this is all that is needed. Thank you!

bodiroga commented 4 years ago

I created unmanaged Items.

Using the script engine? :stuck_out_tongue_closed_eyes:

this device specifically does not report lux or solar radiation, but some number that the manufacturer made up.

Yep, lots of manufacturers report the illuminance as a 0-100 value, that sucks.

I concur, but have no idea if this is all that is needed. Thank you!

It's a pleasure @openhab-5iver, thanks for all the work you have done in the automation area! And let's hear what @cdjackson has to say before doing anything!

5iver commented 4 years ago

Using the script engine?

Nope... using a .rules file, but I can create them using a script. Both managed and unmanaged Items can be created using scripted automation. The Jython helper libraries have a module for this that uses a ManagedItemProvider. I haven't released it yet, I have added the ability to use either an ItemProvider or ManagerItemProvider.

thanks for all the work you have done in the automation area!

:+1:

cdjackson commented 4 years ago

I would agree.... ;)

I agree that probably the channel definition is probably wrong in the XML - it should be Number:Illuminance.

However, I'm not sure that will help at all actually - I suspect that my implementation may be wrong, and if we change the channel definition, it won't actually help since it will still not be possible to convert % to lux. Probably we can't solve that issue with UoM.

I also agree that UoM probably needs some revisiting - in the binding, and generally. I really would have liked to see more system channels so that there's a more standard way to do "everything". I've tried pushing that in the past and been told it's unnecessary, but IMHO it means every binding implements something different, and the poor users have to work out how things work.

There are a lot more system channels now than there were, and in future I might look to change the binding to use more of them - not a job for "right now" though, but I will probably have an OH3 version of the binding (just the OH2 version refactored) very soon.

bodiroga commented 4 years ago

... but I will probably have an OH3 version of the binding (just the OH2 version refactored) very soon.

Looking forward to trying it out :wink: