LightwaveRF Binding Updated

Fixer · February 9, 2020, 9:33pm

Yes that will get around the problem with not picking up the unique names for the outlets/dimmers. I just need to have a careful think about how I do it - all my LWRF devices are already discovered in Alexa using their unique names, so I need to make sure whatever I do now in OpenHAB with LWRF doesn’t confuse the Magic Cylinder or I’ll provoke domestic outrage

Update - I notice it;s also outputting a [WARN] level log entry for each successful http response. for example:

2020-02-09 21:44:30.034 [WARN ] [ab.binding.lightwaverf.internal.Http] - response:{“5a6a3fbfc211836b17f98f26-146-3157328472+0”:887,“5a6a3fbfc211836b17f98f26-147-3157328472+0”:3774215,“5a6a3fbfc211836b17f98f26-148-3157328472+0”:-79}

Fine for now, but it will need to be turn-off-able at some stage or my logs will be deluged

delid4ve · February 9, 2020, 10:11pm

Yeah that was the interim I was using the response to see rgb value, new version just about to upload cut out all logging at warn level except connection issues.

Are you using the Alexa skill for lightwave? Or are they added to Alexa from openhab? If the first then just don’t tag them and they won’t be discovered. If the 2nd then you can create a copy of your items file to mimic the old one (just add the channel to the end)

Personally I’d use the lightwave skill with Alexa instead of through openhab, otherwise your going cloud(amazon) -> cloud(openhab) -> home(openhab) -> cloud (lightwave)…
A lot of connections to rely on there

@Fixer cut down logging version just uploaded. have added version suffix to jar so you can all make sure latest version.

Fixer · February 10, 2020, 11:31am

Behaving itself properly now. Deleted the old .jar, waited 10 secs, dropped the new .jar in, it picked up the existing things and worked fine.
I just have it polling the energy monitor at present in parallel with the scripts. Going to start migrating across one of each type of device one at a time and will report how that goes.

Energy monitor looking good now:

UPDATE

When I discover with the latest version Paper UI discovers stuff but marks every one of them as Unknown Device:

However when I click the tick to add one it has the correct description at that point:

FURTHER UPDATE
Migrated a Gen 1 plug-in socket. Working perfectly

delid4ve · February 10, 2020, 3:03pm

might be a cache issue where they wasnt deleted from inbox…
full textual configs on readme now.

I have 65 channels linked at the moment through text based config and its all working proper.
v1.0.2 added to git a minute ago aswell.

Fixer · February 10, 2020, 3:06pm

Top job. I’ll migrate and test the dimmers next since you don’t have those.
FYI I’m adding them through Paper UI and then updating my text items to point to them. Then I remove them from the refresh and switch rules

delid4ve · February 10, 2020, 3:16pm

why dont you add a thing file and add your devices into it one by one…
I use text files for everything as if you get problems like you did last night and cant recover then when you start fresh item links to things are gone.

delid4ve · February 10, 2020, 3:50pm

yeah id like to know if dimmers:
A - adding ok now
B - recieving and sending updates ok now
C - if the channel types are right.

See about item names (as per git comment) - they can be what you want.

Fixer · February 10, 2020, 4:40pm

Single-gang Gen 2 dimmer added ok via Paper UI.
Switch and dimmer level both working ok for both control push and status monitoring, power and energy measurements are also working.
Going to have a play with some of the more esoteric things such as LED and protection to confirm they work also

delid4ve · February 10, 2020, 4:44pm

I havnt tested whether the led actually changes colour yet… lightwave only give you preset options whereas you have access to the full spectrum. be nice to know we can use whatever colour we want.

If you havnt updated to 1.0.3 the brightness will throw an error so dont change it, just color and saturation.

Fixer · February 10, 2020, 5:26pm

Can’t work out what dimSetup and bulbSetup do. As switches nothig happens, as strings they are blank and as numbers they return 0.

Don’t know what periodOfBroadcast is for either, it returns no value at all no matter what I do.

The identify feature does indeed work and it’s correct as a switch, if you turn it on the dimmer LED starts flashing somewhat manically in white. I was afraid it wasn’t going to stop either but it did about 10 seconds after I’d switched it off again.

The rgbColor is interesting. It’s probably right as type Color. It gives you a colour chooser with a saturation bar at the bottom. Two observations on this -

When you first open the color chooser that saturation bar is sat at zero even though the LED is full on. Dragging the sat bar up and down changes the brightness of the dimmer LED and thereafter the sat bar reads correctly. Being able to change the brightness of the LED on the dimmer was a fairly recently added extra feature by LWRF that came in an updated version of the app. It’s actually very useful for when the dimmer is in a bedroom etc and you don’t want a honking great red LED glaring at you at night.

The colour chooser as it stands doesn’t work. If I drag over to green the LED on the dimmer flashes for a bit showing that something is being sent to it but it stays blue. If I then drag the sat bar up and down the LED dimmer still works even though the colour hasn’t obeyed. Same for red, yellow etc, something’s being sent to the dimmer but the colour doesn’t respond. I captured what’s actually in the initial ‘blue’ setting in the logs below in case it helps you figure it out

Logs:

2020-02-10 16:52:46.146 [.ItemChannelLinkAddedEvent] - Link ‘Lightwave_MorningRoomLight_dimSetup-lightwaverf:d21:77328298:29:1#dimSetup’ has been added.
2020-02-10 16:52:46.150 [.ItemChannelLinkAddedEvent] - Link ‘Lightwave_MorningRoomLight_bulbSetup-lightwaverf:d21:77328298:29:1#bulbSetup’ has been added.
2020-02-10 16:52:46.154 [.ItemChannelLinkAddedEvent] - Link ‘Lightwave_MorningRoomLight_identify-lightwaverf:d21:77328298:29:1#identify’ has been added.
2020-02-10 16:52:46.157 [.ItemChannelLinkAddedEvent] - Link ‘Lightwave_MorningRoomLight_periodOfBroadcast-lightwaverf:d21:77328298:29:1#periodOfBroadcast’ has been added.
2020-02-10 16:52:46.161 [.ItemChannelLinkAddedEvent] - Link ‘Lightwave_MorningRoomLight_rgbColor-lightwaverf:d21:77328298:29:1#rgbColor’ has been added.
2020-02-10 16:52:47.760 [vent.ItemStateChangedEvent] - Lightwave_MorningRoomLight_dimSetup changed from NULL to 0
2020-02-10 16:52:47.762 [vent.ItemStateChangedEvent] - Lightwave_MorningRoomLight_bulbSetup changed from NULL to 0
2020-02-10 16:52:47.798 [vent.ItemStateChangedEvent] - Lightwave_MorningRoomLight_identify changed from NULL to OFF
2020-02-10 16:52:47.824 [vent.ItemStateChangedEvent] - Lightwave_MorningRoomLight_rgbColor changed from NULL to 261.4379284428615,100.0,0.3921569

Havent tested the remaining stuff like reset and checkForUpgrade etc as I don’t fancy knackering my dimmer just when it’s going dark!

UPDATE

Here you can see the colour value changing and being reported back by the API. So I wonder why the LED isn’t responding? Perhaps the firmware in the dimmer will only accept a set of particular values for the LWRF defined colours? I’ll have to test this theory later

2020-02-10 17:06:26.725 [ome.event.ItemCommandEvent] - Item ‘Lightwave_MorningRoomLight_rgbColor’ received command 4,88,100
2020-02-10 17:06:26.730 [nt.ItemStatePredictedEvent] - Lightwave_MorningRoomLight_rgbColor predicted to become 4,88,100
2020-02-10 17:06:26.748 [vent.ItemStateChangedEvent] - Lightwave_MorningRoomLight_rgbColor changed from 260.3921628465839,98.039215,100.0 to 4,88,100
2020-02-10 17:06:27.002 [ome.event.ItemCommandEvent] - Item ‘Lightwave_MorningRoomLight_rgbColor’ received command 4,88,100
2020-02-10 17:06:27.004 [nt.ItemStatePredictedEvent] - Lightwave_MorningRoomLight_rgbColor predicted to become 4,88,100

Also you need some error handling as the colour chooser seems to allow invalid values to be generated and that throws an exception:

2020-02-10 17:06:29.093 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: Hue must be between 0 and 360
at org.eclipse.smarthome.core.library.types.HSBType.validateValue(HSBType.java:105) ~[?:?]
at org.eclipse.smarthome.core.library.types.HSBType.(HSBType.java:97) ~[?:?]
at org.openhab.binding.lightwaverf.internal.handler.DeviceHandler.updateChannels(DeviceHandler.java:377) ~[?:?]
at org.openhab.binding.lightwaverf.internal.handler.DeviceHandler.updateChannels(DeviceHandler.java:323) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_222]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

delid4ve · February 10, 2020, 5:44pm

this should be fixed in version 1.0.2 onwards

I have no clue as these only come on dimmers… its when you set them up for brightness limits etc but i dont know what type they should be, maybe @xela can have a look on postman what they respond with when querying values.

again i have no clue, mine report random integers but i cant work out what

oh so this does actually work? handy to know

i wont be checking rest either

have you added a 2 way dimmer yet? does it work?

Fixer · February 10, 2020, 6:48pm

Plot thickens.
LWRF documentation says the LED colour is for changing the colour of the OFF indication, you can’t chnage the on colour which is always blue.
So I turned the light off and had another go - and it still doesn’t change the colour. The LED brightness still works though and the one setting affects both the off and on LED indications the same.
So from there I thought I’d change the ‘off’ LED colour using the LWRF app and capture the values in the log as the binding sees them change. But they don’t change - nothing happens at all even though in the app I change the LED through all its possible colours. Two conclusions - 1) the app doesn’t use the public API, there’s a private channel as well. 2) LWRF haven’t properly implemented this feature in the public API yet so we’re chasing our tail trying to get it to work in the binding. Probably better to document this as a known issue and move on to something else.
At least the LED brightness works though, tht’s useful to have

delid4ve · February 10, 2020, 7:00pm

The Color value defo changes from app to openhab as I’ve checked with postman and you see the slider move, and generates log (turned off now after testing)

On way home now so give me 30 and I’ll let you know

Fixer · February 10, 2020, 7:33pm

2-gang Gen 2 dimmer successfully added from Inbox and working ok

delid4ve · February 10, 2020, 7:48pm

Color does change, however it’s limited to the colours in the app and will adjust to the nearest value

I’ll leave as is though so you still get access to the brightness

Fixer · February 10, 2020, 7:50pm

Are you testing that with a socket?

delid4ve · February 10, 2020, 7:50pm

Yes, gen2 double

xela · February 10, 2020, 7:52pm

Do you see both dimmers?

Fixer · February 10, 2020, 7:53pm

I’ll try adding my socket later then and see if it works for me too

delid4ve · February 10, 2020, 7:53pm

Didn’t upload video

It’s defo working, just restricted

Oh and you can see my period of broadcast in the photo - 16… don’t know what it refers to, been on longer than 16 days, off within 16 weeks… god knows