search

cyrilcc / org.openhab.binding.rflink

RFLink binding for OpenHAB 2.0
23 stars 35 forks source link

Dimmer NewKaku #39

Closed rutgerputter closed 5 years ago

rutgerputter commented 5 years ago

Hi there,

This binding is working great for me, thanks so much for the hard work!

There is one request I would like to make. There is currently no Dimmer support for NewKaku devices. Could you add a channel for these device?

The RFLINK Syntax would be something like this: 20;04;NewKaku;ID=000007;SWITCH=2;CMD=SET_LEVEL=14;

A normal Switch is almost the same: 20;04;NewKaku;ID=000007;SWITCH=2;CMD=ON;

So there would only have to be a SET_LEVEL from 0 to 100% in there. I hope this is easy enough to code.

Thanks for considering!

cartemere commented 5 years ago

Hi,

I made a quick update on the "Switch" behavior to handle this specific "dimming" command. https://github.com/cartemere/org.openhab.binding.rflink/commit/ce3d20704e153dab69ae0a18fdfddb51c5ce1a65

The code is passing successfully the new unit test added : https://github.com/cartemere/org.openhab.binding.rflink.test/commit/68fe16f99ef5d4a6ba7becba772e575fdec5c46f

HOW TO USE IT ? The update adds a new channel on the Switch binding : "dimminglevel". This state is filled ONLY on NewKaku Dimming events received. Other events will NOT have this attribute. On the other side : these specific Dimming events will have contact=UNDEF & command=UNDEF, as the event does not contain any of these information. The value of the "dimmingLevel" is an integer, reflecting the level value received (tell me if you prefer a double representing a percentage or whatever).

WHERE IS THE DISTRIB ? it is currently being rebuilt by the travis Job, you should have a new Jar within a few minutes here : https://github.com/cartemere/org.openhab.binding.rflink/releases

Let us know if you have any suggestion or issue

michaelbouma commented 5 years ago

Looks like the NewKaku doesn't work anymore after this change. Discovery is OK but I do not see state changes for NewKaku devices.

cartemere commented 5 years ago

Unfortunately I don't have any NewKaku device, so I worked on this using a unitTest created by myself. Can you provide your Openhab logs, so I can investigate the behavior ?

michaelbouma commented 5 years ago

This is what happens when I try to send the Dimmer command:

19:59:19.347 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Kaku_EettafelDim' received command 22
19:59:19.350 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.rflink.handler.RfLinkHandler@2a536076': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.22
java.lang.IllegalArgumentException: No enum constant org.eclipse.smarthome.core.library.types.OnOffType.22
        at java.lang.Enum.valueOf(Enum.java:238) ~[?:?]
        at org.eclipse.smarthome.core.library.types.OnOffType.valueOf(OnOffType.java:1) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
        at org.openhab.binding.rflink.messages.RfLinkSwitchMessage.initializeFromChannel(RfLinkSwitchMessage.java:126) ~[?:?]
        at org.openhab.binding.rflink.handler.RfLinkHandler.handleCommand(RfLinkHandler.java:67) ~[?:?]
        at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at com.sun.proxy.$Proxy129.handleCommand(Unknown Source) [218:org.openhab.binding.rflink:2.3.0]
        at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
        at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
        at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
19:59:19.352 [INFO ] [arthome.event.ItemStatePredictedEvent] - Kaku_EettafelDim predicted to become 22
19:59:19.391 [INFO ] [smarthome.event.ItemStateChangedEvent] - Kaku_EettafelDim changed from NULL to 22

This is my items entry Dimmer Kaku_EettafelDim "Eettafel dimmer" <light> (GF_Dining) [ "Lighting" ] { channel="rflink:switch:usb0:NewKaku_00270800_5:dimminglevel" }

cartemere commented 5 years ago

Thank you for the log. I will try to work on it tonight :)

Le lun. 21 janv. 2019 à 20:03, michaelbouma notifications@github.com a écrit :

This is what happens when I try to send the Dimmer command:

19:59:19.347 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Kaku_EettafelDim' received command 22 19:59:19.350 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.rflink.handler.RfLinkHandler@2a536076': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.22 java.lang.IllegalArgumentException: No enum constant org.eclipse.smarthome.core.library.types.OnOffType.22 at java.lang.Enum.valueOf(Enum.java:238) ~[?:?] at org.eclipse.smarthome.core.library.types.OnOffType.valueOf(OnOffType.java:1) ~[102:org.eclipse.smarthome.core:0.10.0.oh240] at org.openhab.binding.rflink.messages.RfLinkSwitchMessage.initializeFromChannel(RfLinkSwitchMessage.java:126) ~[?:?] at org.openhab.binding.rflink.handler.RfLinkHandler.handleCommand(RfLinkHandler.java:67) ~[?:?] at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240] at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240] at com.sun.proxy.$Proxy129.handleCommand(Unknown Source) [218:org.openhab.binding.rflink:2.3.0] at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240] at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] at java.lang.Thread.run(Thread.java:748) [?:?] 19:59:19.352 [INFO ] [arthome.event.ItemStatePredictedEvent] - Kaku_EettafelDim predicted to become 22 19:59:19.391 [INFO ] [smarthome.event.ItemStateChangedEvent] - Kaku_EettafelDim changed from NULL to 22

This is my items entry Dimmer Kaku_EettafelDim "Eettafel dimmer" (GF_Dining) [ "Lighting" ] { channel="rflink:switch:usb0:NewKaku_00270800_5:dimminglevel" }

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyrilcc/org.openhab.binding.rflink/issues/39#issuecomment-456172076, or mute the thread https://github.com/notifications/unsubscribe-auth/AoJoAZGbS2aRXBs85_ayQTtQSyXBi8iwks5vFg8PgaJpZM4Zgapi .

neilstreet6036 commented 5 years ago

I have exactly the same issue. Both when sending on/off commands or an integer value for the dimmer.

019-01-22 16:26:20.574 [ome.event.ItemCommandEvent] - Item 'Switch_FF_Bedroom_Master_Reading_Right' received command ON 019-01-22 16:26:20.602 [nt.ItemStatePredictedEvent] - Switch_FF_Bedroom_Master_Reading_Right predicted to become ON 2019-01-22 16:26:20.616 [vent.ItemStateChangedEvent] - Switch_FF_Bedroom_Master_Reading_Right changed from OFF to ON ==> /var/log/openhab2/openhab.log <== 2019-01-22 16:26:20.635 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.rflink.handler.RfLinkHandler@14f2490': null java.lang.NullPointerException: null at org.openhab.binding.rflink.messages.RfLinkBaseMessage.buildMessage(RfLinkBaseMessage.java:156) ~[?:?] at org.openhab.binding.rflink.messages.RfLinkBaseMessage.buildMessages(RfLinkBaseMessage.java:146) ~[?:?] at org.openhab.binding.rflink.handler.RfLinkBridgeHandler$TransmitQueue.send(RfLinkBridgeHandler.java:76) ~[?:?] at org.openhab.binding.rflink.handler.RfLinkBridgeHandler$TransmitQueue.enqueue(RfLinkBridgeHandler.java:65) ~[?:?] at org.openhab.binding.rflink.handler.RfLinkBridgeHandler.sendMessage(RfLinkBridgeHandler.java:162) ~[?:?] at org.openhab.binding.rflink.handler.RfLinkHandler.handleCommand(RfLinkHandler.java:75) ~[?:?] at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240] at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240] at com.sun.proxy.$Proxy128.handleCommand(Unknown Source) [233:org.openhab.binding.rflink:2.3.0] at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240] at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240] at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?] at java.lang.Thread.run(Thread.java:748) [?:?]

cartemere commented 5 years ago

I implemented only the reception side, with a "composite" CMD value coming from the bridge, like 20;04;NewKaku;ID=000007;SWITCH=2;CMD=ON; 20;04;NewKaku;ID=000007;SWITCH=2;CMD=SET_LEVEL=14; according to the protocol reference available here : http://www.rflink.nl/blog2/protref

But I did not implement the Dimming transmission, what's why it was failing. ^^

BEWARE : according to the documentation, the bridge seems to understand values between 1 - 15 : 10;NewKaku;00c142;1;ON; => Newkaku/AC protocol;address (24 bits);button number (hexadecimal 0x0-0x0f);action (ON/OFF/ALLON/ALLOFF/15 - 1 to 15 for direct dim level) 10;NewKaku;128ac4d;1;OFF; => Newkaku/AC protocol;address (28 bits);button number (hexadecimal 0x0-0x0f);action (ON/OFF/ALLON/ALLOFF/15 - 1 to 15 for direct dim level)

I can map value 0 to OFF But I don't know what I should do if > 15 ?? Should I use a Percent type and map values 0-15 as 0%-100% ?? And perhaps do the same for reception dimming values ??

neilstreet6036 commented 5 years ago

Hi,

From my perspective if you are sending a dimming value, then an integer in the 0 to 15 range would be correct as that is how the kaku devices work. I cant see any mileage in mapping to a percentage, it adds complication. That could be handled on OH by a rule if people want their sliders to work in that way. That's just my preference and opinion.

If you are sending a command, which the dimmers will handle, then ON and OFF

If a value > 15 if received, why not set it 15?

Thanks for looking so promptly at the issue, it will be a great help to get this binding up and running.

Kr, Neil

cartemere commented 5 years ago

I improved the behavior with your advice. So on a Dimming command, value is automatically capped between 1-15 if value is <1, then "OFF" command is sent to bridge.

states "command" and "contact" are updated on each instruction sent.

the tests have been updated to reflect these changes : https://github.com/cartemere/org.openhab.binding.rflink.test/commit/5ba562561a3d5a87117008ecaf6361eb16ebd473

neilstreet6036 commented 5 years ago

Thank you, dimmers work perfectly! I am having trouble with switches though, they are not always receiving the ON/OFF commands, there is nothing in the log to suggest there are any issues but when you press the button nothing happens. Not sure if anyone else has experienced this behavior?

One ask, would be to add the functionality for the RFLink Special Control Command set. This could be implemented by just adding the sending of the string with the value being attributed by an Openhab string item.

Kr Neil.

cartemere commented 5 years ago

Hello,

Following request #42, I also implemented support for ALLON and ALLOFF commands (the commit was pushed yesterday). But I don't think your reception issue is linked to this, as OpenHab logs a verbose error while this happens.

I am also experiencing events from the bridge disappearing mysteriously, I will try to figure out why. From what I tested lately, I guess we may have an issue in the way the plugin "reads" the messages from the RfLink bridge.

I will post on this thread if I found a solution.

Cartemere

Le ven. 25 janv. 2019 à 20:09, neilstreet6036 notifications@github.com a écrit :

Thank you, dimmers work perfectly! I am having trouble with switches though, they are not always receiving the ON/OFF commands, there is nothing in the log to suggest there are any issues but when you press the button nothing happens. Not sure if anyone else has experienced this behavior?

One ask, would be to add the functionality for the RFLink Special Control Command set. This could be implemented by just adding the sending of the string with the value being attributed by an Openhab string item.

Kr Neil.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyrilcc/org.openhab.binding.rflink/issues/39#issuecomment-457688437, or mute the thread https://github.com/notifications/unsubscribe-auth/AoJoAQgOuOumg4Ye0c-NiZzXCFF09s4_ks5vG1Z2gaJpZM4Zgapi .

neilstreet6036 commented 5 years ago

Thanks for your great work, its is so much easier using the binding than pushing through a wifi/mqtt/rf bridge. I suspect that the disappearing events is what i am experiencing but only on switches not dimmers.

Kr, Neil.

cartemere commented 5 years ago

And about the functionality you are thinking about (i.e. being able to send a "raw" command), I am working on a kind of "admin" tools.

These would be attached to the "bridge" thing itself (as it is not linked to any remote thing), and would provide :

Le sam. 26 janv. 2019 à 17:57, neilstreet6036 notifications@github.com a écrit :

Thanks for your great work, its is so much easier using the binding than pushing through a wifi/mqtt/rf bridge. I suspect that the disappearing events is what i am experiencing but only on switches not dimmers.

Kr, Neil.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyrilcc/org.openhab.binding.rflink/issues/39#issuecomment-457846711, or mute the thread https://github.com/notifications/unsubscribe-auth/AoJoAbwlrMsYFnxYOVj9fk56P_KlPnamks5vHIjhgaJpZM4Zgapi .

neilstreet6036 commented 5 years ago

That sounds great, if the special command set is accessible it will help with diagnostics etc. With my mqtt bridge i used to send a ping every 3 minutes for a keep-alive. If it takes time for the serial bridge to 'wake' to execute a command on the serial port, then having an option for sending a ping before the command may help. But also great for building a habpanel status widget for monitoring the bridge :)

Thanks for your work, impressed so far.

Kr, Neil.

syrisara commented 5 years ago

I want to say thank you for this binding. Although I have to test the dimmer support it is working great. for switching and receiving temperatures etc. If dimming works I can sell my RFXcom which I only use for dimming my dimmers.

Keep up the good work.

syrisara commented 5 years ago

Hi,

From my perspective if you are sending a dimming value, then an integer in the 0 to 15 range would be correct as that is how the kaku devices work. I cant see any mileage in mapping to a percentage, it adds complication. That could be handled on OH by a rule if people want their sliders to work in that way. That's just my preference and opinion.

If you are sending a command, which the dimmers will handle, then ON and OFF

If a value > 15 if received, why not set it 15?

Thanks for looking so promptly at the issue, it will be a great help to get this binding up and running.

Kr, Neil

Are we sure here? I tried the dimmer support (finally had some time) however at 15% slider level as Item the brightness of the lamp is 100%? Is this intended to happen? Or am I missing something?

Thank you,

cartemere commented 5 years ago

Hello Syrisara,

For now, as asked by Neil, there is no input type conversion. The plugin is expecting a "raw" value that will be sent through the bridge. So an integer between 0 and 15. If you want another range of input (ex: between 0 and 100 for a percentage), you can do the conversion through a OpenHab rule, as Neil suggest.

I can anyway implement a 'percent' handler : if the input value is a 'PercentType', then I can convert it to a value between 0 and 15. (this should be easy)

Le ven. 1 févr. 2019 à 17:38, syrisara notifications@github.com a écrit :

Hi,

From my perspective if you are sending a dimming value, then an integer in the 0 to 15 range would be correct as that is how the kaku devices work. I cant see any mileage in mapping to a percentage, it adds complication. That could be handled on OH by a rule if people want their sliders to work in that way. That's just my preference and opinion.

If you are sending a command, which the dimmers will handle, then ON and OFF

If a value > 15 if received, why not set it 15?

Thanks for looking so promptly at the issue, it will be a great help to get this binding up and running.

Kr, Neil

Are we sure here? I tried the dimmer support (finally had some time) however at 15% slider level as Item the brightness of the lamp is 100%? Is this intended to happen? Or am I missing something?

Thank you,

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cyrilcc/org.openhab.binding.rflink/issues/39#issuecomment-459784678, or mute the thread https://github.com/notifications/unsubscribe-auth/AoJoAfbIcuD2Gj9qixtelxfllc7Z-Uumks5vJG2fgaJpZM4Zgapi .

syrisara commented 5 years ago

Thank you for your (very) fast reply.

A percent handler would be great, I think that is a clean solution without generating extra overhead because of the use of rules. If you could be so kind to implement this you at least make me happy :-)

Thank you for your effort to make this binding mature!

cartemere commented 5 years ago

Hello,

I just pushed a new development. This adds support for INPUT PercentType for Dimming command on NewKakuDevices. You can now send a PercentType (value between 0 - 100) to the Thing. This PercentType will be automatically converted to a 'valid' DecimalType value (between 0-15), and the converted value will be processed by the RfLink plugin.

Please note : the 'dimmingLevel' state on the Thing is still expressed in the native format (i.e. between 0-15).

I added a new UnitTest to cover this behavior : https://github.com/cartemere/org.openhab.binding.rflink.test/commit/07bc7c083f86ce125e797e42861b5976c63fa9a4 sending an command with a PercentType(80) to the RfLink plugin will end in a command with "12" as DimmingValue to the bridge (80% = 12/15)

syrisara commented 5 years ago

Thank you for this addition,

RFLink working great, dimming 0-100% is working perfectly. Now I can say goodbye to my RFXCom.

Thank to those who are making this binding great!

cartemere commented 5 years ago

@neilstreet6036

One ask, would be to add the functionality for the RFLink Special Control Command set. This could be implemented by just adding the sending of the string with the value being attributed by an Openhab string item.

Kr Neil.

Hello !

This is now implemented, according to change cyrilcc#44

neilstreet6036 commented 5 years ago

Thank you; I'll give it a try as soon as i get the chance.

Kr,

Neil.

cartemere commented 5 years ago

Anyway, I can close this issue as it is now working as expected

neilstreet6036 commented 5 years ago

Thank you, for the addition. I am still experiencing issues with newkaku switches, they still appear to be problematic. Sometimes they work and sometimes they dont. At first i though it was because the rflink couldn't cope with the pace of the signals, i now have a delay of one minute between items in a group, some switches turn on and off and some don't. Its very hit and miss as to which ones work. Dimmers are great, no problems at all. The Openhab event log shows all of the commands being processed, but the switches don't always turn on. I know you said you had noticed similar??