LightwaveRF Binding Updated

Add-ons Bindings
483

@Fixer @xela @s73ven @Greigc
Only sockets integrated at present but have a look see what errors come up, hopefully all good. Give me any feedback (still alot of work to be done)
remove the pdf extension.

org.openhab.binding.lightwaverf-2.5.2-SNAPSHOT.jar.pdf (64.3 KB)

I have put reset/upgrade etc on the main device,
featuresets are what you want for the actual switches etc)

start by adding an account with username and password, then run discovery

I’ll get it all on git once I’ve added the other devices later on

484

@delid4ve Will PM you my structure shortly

485

New version:

  • Thermostat integrated
  • Dimmers integrated.
  • Removed FeatureSet prefix (put in for testing)
  • Fixed Api linit being hit and changed polling process

org.openhab.binding.lightwaverf-2.5.2-SNAPSHOT_v1.1.jar.pdf (71.0 KB)

If you added lots of devices prior to this version you will probably have to remove them and re-add as i haven’t added configuration updates in yet

486

Cool. I’m out rest of today, will try to have a go Wednesday.
As a matter of interest, how did you improve the polling process?

487

So with the script it was fetching every bit of data in one go, for me that doesnt work and i had to split it in to 2 x scripts due to the amount of devices ({structure not found}) - same goes if i try in the binding.

I initially was polling for each channel individually to test - ({API rate limit exceeded}) once i got over about 6 devices

So it now works as follows:
For each ‘Thing’ the binding does a batch data read for its channels and updates accordingly.
Its quite a heavy process as I have to evaluate the item data against the response but it seems to be working ok. Ive since also changed the code slightly to make it more efficient and I’m still evaluating other ways I can process the data.
At present with 40 devices (double sockets count as 2) I can get the polling to every 18 seconds (just because of the amount of Http requests)
The binding doesn’t have much error checking at present (set to debug or trace if you want to flood your logs)

Like i say, plenty to do still, oh and I havent implemented all updates from openhab --> lightwave yet so don’t be suprised if setting a temperature doesnt work at present. All status changes from lightwave --> openhab should be working though.

Ill be working on more this week and will keep you all updated, if you could do the same the other way.

488

I’m back home on Saturday, I’ll have a play over the weekend

489

There’s a newer version available, have uploaded everything to git now.
Assuming no one has tested yet due to the radio silence?
Have changed the refresh method to only poll for linked items, in groups of 30 to avoid structure not found. so if you have polling interval set to 5 seconds with 31 items linked, it will refresh every 10 seconds, 61 - 15 seconds…
the only way I could get the most out of the api. i will probably add a parameter in so you can set how many items at once it fetches but i done tests with postman and 30 was the optimal (per item).

490

I’ve literally just (5 minutes ago) downloaded it :rofl:

I’ll grab the new version from git

491

Yeah not been able to do much, had the flu or something similar. Getting back to it now though.
2 questions:

Will it rediscover and/or name my devices differently? I have some automation rules I’ll need to amend if so.

Do you have the device status push working as well yet, or just the refreshes? Again, without the control ability I’ll have to time my testing carefully as my house will stop working and I’ll get severely nagged!

Also, goes without saying, total appreciation for all your work on this. Top man!

492

Get better soon. The big thing is i only have double sockets to test on, no other devices.
control should be working (have changed a few bits today and still at the office so don’t wanna freak the missus out testing)
it wont overwrite anything from the script, the worst case is you’ll hit the api limits where your polling twice - treat it as a binding, not rules like you have at present. So they will work in tandem. everything you have is textual config, for the time being this is discovery only

493

I added the binding earlier, it’s discovered the devices fine and I can add the lightswitches/thermostat.

I can turn the light switches on/off, but the dimmer doesn’t seem to be working (it sends something as the hub flashes)

The state doesn’t seem to be updating at all though (dimmers dont change when updated on app and thermostat has no values at all)

I do see this however

19:07:39.818 [DEBUG] [waverf.internal.handler.DeviceHandler] - Update device 'Heating' channels
19:07:39.820 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.821 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.822 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.823 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.825 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.827 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.828 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
19:07:39.829 [DEBUG] [waverf.internal.handler.DeviceHandler] - Finished Channel Update for org.eclipse.smarthome.core.thing.internal.ThingImpl@fbd6d954
494

Yay we are getting somewhere :muscle:
Just eating dinner and I’ll take a look.
@xela you using the latest version off git yeah?
I found the reason it wasnt sending, going to look for why it’s not receiving now

have just uploaded a new jar to git.

495

Will grab it now and test

496

I did this while I was away getting the structures for you and hit the wrong thing, twice :rofl:

497

Heating:

  • It’s pulling the values from LW and they’re updating when I change them on the app
  • Are you doing anything with the BatteryLevel, the logs suggest it’s 49, but for some reason it’s coming up as 5
  • Changes are not going from openhab->LW

Dimmers:

  • Changes are working openhab->LW (Both Switch and DimLevel)
  • Binding has pulled values at some point as they’re populated (on the test one I’ve done), but don’t seem to be updating

Will continue to test more

498

This should all be working now (new version uploaded to git)

See if there’s anything that comes up in the logs when you change the values

499

Received command ‘19.5’ to channel lightwaverf:thermostat:f0162a74:5df8b6728522075debd21ad8_7_3157346060_1:targetTemperature
21:07:47.354 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.lightwaverf.internal.handler.DeviceHandler@706f9437’: null
java.lang.NullPointerException: null
at org.openhab.binding.lightwaverf.internal.handler.DeviceHandler.handleCommand(DeviceHandler.java:316) ~[?:?]
at sun.reflect.GeneratedMethodAccessor134.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy556.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]

500

new version pushed to git, try now

501

Ok, heating seems to be working perfectly now (I’ve only checked current and target temps so far and the battery level, will check some of the other metrics tomorrow)

Still not getting dimmer updates from LW->Openhab, I don’t seem to see anything come through at all for those, I got several of these in the logs when I replaced the binding, not sure if the task fails to create?:

[WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: Value must be between 0 and 100
at org.eclipse.smarthome.core.library.types.PercentType.validateValue(PercentType.java:57) ~[?:?]
at org.eclipse.smarthome.core.library.types.PercentType.(PercentType.java:52) ~[?:?]
at org.eclipse.smarthome.core.library.types.DecimalType.as(DecimalType.java:152) ~[?:?]
at org.eclipse.smarthome.core.internal.items.ItemStateConverterImpl.convertToAcceptedState(ItemStateConverterImpl.java:64) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.sendUpdate(ProfileCallbackImpl.java:134) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onStateUpdateFromHandler(SystemDefaultProfile.java:53) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.lambda$9(CommunicationManager.java:467) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.lambda$11(CommunicationManager.java:487) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.handleCallFromHandler(CommunicationManager.java:483) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.CommunicationManager.stateUpdated(CommunicationManager.java:465) ~[?:?]
at org.eclipse.smarthome.core.thing.internal.ThingManagerImpl$1.stateUpdated(ThingManagerImpl.java:168) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:245) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:264) ~[?:?]
at org.openhab.binding.lightwaverf.internal.handler.FeatureSetHandler.updateChannels(FeatureSetHandler.java:215) ~[?:?]
at org.openhab.binding.lightwaverf.internal.handler.FeatureSetHandler.updateChannels(FeatureSetHandler.java:186) ~[?:?]
at org.openhab.binding.lightwaverf.internal.handler.FeatureSetHandler.updateStateAndChannels(FeatureSetHandler.java:152) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_232]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]

PS, great work so far!

502

can anyone confirm the login server is down at present?
getting 404 Not Found

20 mins later its back up…