Dimming WAY is not standard

[GoogleCodeExporter]

Hi,
I discovered a issue in dimming management.
Just assume I have a KNX dimmer object on the bus named "D1", its GA is 0/0/70 
for the switch and 0/0/72 for the brightness value.
The physical object "remembers" the last used brightness, so if I send (trough 
a physical switch or ETS4 command line debugger) a "ON" command to GA 0/0/70, 
it turns on at the brightness value that had before the last "OFF" command. 
This option is manageable via ETS4, the KNX configurator, as physical object 
property.

The issue is that openHAB allways send "100" to the GA 0/0/72 after a "ON" 
command to the GA 0/0/70.
This causes two unwanted actions:

1. When D1 is off and I send a command "ON" to D1, it turns always on at 100% 
brightness value.

2. When D1 is off and I send a command "5" to D1, it turns on at 100% 
brightness value, and I have to send the same command again in order to see D1 
at 5%.

The command I use on the command line is:
curl -H "Content-Type: text/plain" -d "5" http://localhost:8080/rest/items/D1

The log I see on the terminal in debug mode is:
11:16:27.863 DEBUG o.o.i.r.i.r.ItemResource[:200] - Received HTTP POST request 
at 'items/D1' with value '5'.
11:16:27.864 INFO  runtime.busevents[:42] - D1 received command 5
11:16:27.881 DEBUG o.o.b.k.i.bus.KNXBinding[:162] - Wrote value '5' to 
datapoint 'command DP 0/0/72 D1, DPT main 0 id 5.001, low priority'
11:16:28.053 INFO  runtime.busevents[:42] - D1 received command ON
11:16:31.220 INFO  runtime.busevents[:42] - D1 received command 100

The solution I propose is to not send "100" on the busevent when a "ON" or 
"value" command is sent, because the "standard way" don't do this. You can 
provide to the user a "special way" via "Item definition directives" if he 
needs it.
Thank you.

Original issue reported on code.google.com by evazzo...@gmail.com on 25 Jul 2013 at 9:40

[GoogleCodeExporter]

Please, accept this issue or let's discuss about!

Original comment by evazzo...@gmail.com on 2 Aug 2013 at 7:18

[GoogleCodeExporter]

Does nobody know if I can write a script or rule that disables that "D1 
received command 100" in order to let the actuator decide what is the starting 
brightness?

Original comment by evazzo...@gmail.com on 6 Aug 2013 at 10:20

[GoogleCodeExporter]

Hmm, I think I need more information about this behaviour.
From your log, I absolutely do not understand, why you have commands in the 
sequence 5->ON->100. You only send the "5" and that's it? Where do the ON and 
100 commands come from? Are they issued by the KNX binding when receiving 
updates from the device?
Could you post your KNX binding config string ( {knx="xxx"} ) ?

Original comment by kai.openhab on 7 Aug 2013 at 5:10

[GoogleCodeExporter]

Hi, thank you for the answer.
Yes, with D1 turned OFF I send the "5" value via REST service with the curl 
command I wrote here above. At this point openhab sends a 5, then ON and then a 
100 command. Just note I never sent 100, expecting that the light turns on 
direct at 5%. This is the test 1...
The test 2: I send ON with the same method. Openhab send ON then 100. I was 
expecting that the light turns on at the same value it had when it was turned 
off last time.
If I use the "website" via browser, I hit "up" and the dimmer allways turn on 
at 100%.
My config strings are:

Dimmer D1   "D1 Dimmer [%d %%]" (VA_Valigia, Lights, Dimmers) { knx = 
"1.001:0/0/70, 5.001:0/0/72" }

So I suppose somewere in the openhab code we can find a "send 100" after a 
dimmer's "ON" command.
I don't know where, but this prevent the user to use the useful "memory" 
function in standard dimmer devices.

Original comment by evazzo...@gmail.com on 7 Aug 2013 at 9:54

[GoogleCodeExporter]

Just to collect more data for this issue, I tried to send commands to the 
dimmer via XMPP chat. The result is the same. See attachment.

Original comment by evazzo...@gmail.com on 8 Aug 2013 at 7:25

Attachments:

• [2013-08-08 09.23.48 am.png](https://storage.googleapis.com/google-code-attachments/openhab/issue-386/comment-5/2013-08-08 09.23.48 am.png)

[GoogleCodeExporter]

Why nobody accept this issue??? It's still marked as new...

Original comment by evazzo...@gmail.com on 21 Aug 2013 at 9:54

[GoogleCodeExporter]

After a month, still as "new"... I can pay for an "accept"... :-)

Original comment by evazzo...@gmail.com on 3 Sep 2013 at 12:56

[GoogleCodeExporter]

How much? :-)
Please don't take it personal, this issue is not the only one in status new: 
https://code.google.com/p/openhab/issues/list?can=6

The reason why it is not accepted yet is that I haven't yet reproduced it 
myself. This would need some further time for analysis, which I simply haven't 
found yet. I am happy for anybody helping out and diving with the debugger into 
the code to see why it behaves that way and to propose a bug fix. Sorry that I 
cannot do more right now...

Original comment by kai.openhab on 3 Sep 2013 at 7:43

[GoogleCodeExporter]

Ok, thank you! Sorry for bugging you, really.
If you were Italian, I would have told "I'll pay with a couple of beers"... But 
I don't think is a good Idea: our best beer may be "water" for you... ;-)
Let's speak about a good italian wine bottle!
I'll wait for your free-time studying java (in order to contribute to this 
wonderful project in the future). In the meanwhile, just choose a wine! :-)

Original comment by evazzo...@gmail.com on 3 Sep 2013 at 10:03

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:53

• Added labels: To-Github

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid