I think both ways (separate explicit control for white channel as you implemented and a translation for the w-channel) are valid and needful. Especially, when using unbalanced stripes, you’d prefer the seperate explicite w-control, as rendered colors won’t match to the color picker. When using balanced stripes, you’d prefer the HSV conrol.
A little problem with the DPT 232.600 is, that it is clearly defined for RGB by KNX assoc. Interestingly, MDT uses this DPT also for HSV, which might be purely vendor specific- never seen this elsewhere. Maybe, because there’s no DPT defined for HSV by KNX assoc., yet.
So a modification in DPT 232.600 should be configurable between RGB and HSV mode.
Just my 2 cents
So maybe, a good way to go might be the usage of DPT 251.600 with optional translation for the w-control.
I hope, there are some more opinions on that. Wondering anyways, that there’s no more activity/discussion on that…
Yes, but the conversion depends on the configured FPT. We could work around that by defining a „custom“ DPT like 232.601, but that might be breaking if the KNX sometimes decides to add a DPT with that number.
In my previous post I was thinking of keeping DPT 232.600 untouched and working with DPT 251.600, instead (6 byte RGBW). Because we can use 251.600 as defined by KNX Assoc. (remark: the MDT actuators support this DPT as well).
Just had a look to the datapoint definition document of KNX Assoc.: The DPT subtypes (like xxx.600 or xxx.001) are defined for the dimensions/units and especially the subtypes 600-999 are defined for lighting.
0-99 is for common use
1200-50999 are Reserved
60000 and greater are manufacturer specific
Idea:
We could use a manufacturer specific subtype, as MDTs way is manufacturer specific, from my point of view. This, of course, can still bring along the problem with collisions, when KNX Assoc. officially defines subtypes within that range. But having a collision with that subtype is less likely than using something between 600 and 999, i think. When we define e.g. 262.60000, this would be according to KNX spec. from my point of view. Although it’s not an officially defined DPT subtype.
Or the other idea: Just use the dimensionless maintype “262”
Type color : OG_WohZi_Li_RGB1 "LED Farbe Fernseher" [ hsb="251.600:11/3/141" ]
But still getting the same warning:
Configured DPT '251.600' is incompatible with accepted types '[class org.openhab.core.library.types.OnOffType, class org.openhab.core.library.types.HSBType, class org.openhab.core.library.types.PercentType, class org.openhab.core.library.types.IncreaseDecreaseType]' for channel 'knx:device:bridge:rgb:OG_WohZi_Li_RGB1'
Next step will be to setup a test installation from scratch, just to be sure…
(I’m using textual configuration files only, btw…)
Bridge knx:ip:bridge
[
ipAddress="192.168.1.15",
portNumber=3700,
localIp="192.168.1.24",
type="TUNNEL"
]
{
Thing device rgb [] {
Type color : OG_WohZi_Li_RGB1 "LED Farbe Fernseher" [ hsb="251.600:11/3/141" ]
Type color : OG_WohZi_Li_RGB2 "LED Farbe Couch" [ hsb="232.600:11/3/131+<11/4/131", switch="1.001:1/0/132+<1/1/132", position="5.001:11/3/135+<11/4/135" ]
Type color : OG_WohZi_Li_RGB3 "LED Farbe Ecke" [ hsb="232.600:11/3/181+<11/4/181", switch="1.001:1/0/182+<1/1/182", position="5.001:11/3/185+<11/4/185" ]
}
}
It’s not sending data to KNX. For reference, I included my bridge definition and other DPT 232.600 based thing-definitions, which are working fine.
I did not rebuild the environment, yet…
I rebuilt my test environment from scratch with clean definition files. As soon as i specifiy DPT 251.600 for the thing, I’m getting the warning and no data is sent to KNX through the channel…
I’ve no idea, where the problem is…
Edit: No matter, whether I configured via GUI or textual config-file.
Did you really check-in the correct version for download?
Can you check which version is really active (with list like above)? I downloaded the .kar a minute ago and it works. It should show 3.2.7.202110311549. If you dropped the new .kar while openHAB was not running, it might be that the old version ist still running. If that’s the case, feature:uninstall smarthomej-binding-knx and feature:install smarthomej-binding-knx.
Got it: For some reason the version i got for download was 3.2.7.202110310334
Now, I got the new version you mentioned and the warning has gone and OH is sending the 6 byte value
But there’s a glitch in the encoding, from which I don’t know whether it’s an actuator issue or an KNX binding/encoding issue, as the colors are not set correctly with the colorpicker. As ETS also behaves somehow strange, it might be related to the MDT actuator: You set the last byte to $0E which gives wired results, as well when setting this in ETS. When setting the last byte to $0F, the colors set with ETS are correct. Unfortunately, the DPT 251.600 is not in my datapoint spec document, so I don’t know the correct specs…
I’ll do some more testing and investigation on that, assuming this is an actuator issue. Fortunately, we’re one step further
Can you give me details about the device (Type, HW version, firmware, application)? I‘ll contact MDT.
We could probably work around that by a generic „sendTelegram(DPT, data);“ action on the bridge and construct a full RGBW value in a rule, when either the color or white part changes. But that‘s another PR.
I have added 232.60000 for HSV (encoded in the same way as 232.600).
New Build:
I don’t think I’ll add a workaround for the wrong usage of 251.600. This should be fixed by MDT. As mentioned above, in a Follow-Up-PR I’ll add a rule action.
Wow, great. I’ll test later this evening
I’m with you, regarding the MDT actuator. I’ll spend some further investigations on this, because it’s hard to believe that there is such a bug, as this device is on the market for quite a while. I have several HW revisions of this actuator to take a closer look. Probably, it’s just screwed up, because of the testing and receiving wrong data types on its KO (had some other behaviour beside the color rendering, which i was wondering about). I’ll give the detailed information about the device to you, then (it’s a AKD-0424V.02, btw.).
Oops. I checked that the conversion is working, but not if the channel could be configured. Only 3 or 4 digit-Sub-Types were accepted during config-check.
