Is there someone who want to become the new developer for the TKB Home APP ?
The TKB Home APP is still SDKv2 so it should become SDKv3 to work with the Homey Pro (early 2023)
Are you asking on behalf of the developer?
If itās any help @Dominique_Vanhessche if, like me, you have a large fleet of TKB devices that are either simple on/off or dimmers then you donāt actually need the TKB app, you can re-add them to your system as āBasic Z-Wave Deviceā by tapping āHomeyā in the add device screen and this way you would be able to carry on using them on Homey Pro 2023 when that turns up.
Note that you will need to have the TKB app either disabled or uninstalled at the point when youāre re-adding a device otherwise the add process appears to be clever enough to realise you have a matching app installed and installs it using the TKB app anyway.
1 Like
If this is true, then I am a very satisfied man 
Thanks for your advice 
Hi Dominique or other homey users, were you able to test this allready or waiting for the new homey pro? I only have 3 devices but would still be a shame if i have to replace them.
You can test this for yourself simply by following the instructions in my post above. No need to wait for the new Pro to arrive, you can switch your tkb devices over to native basic z wave devices now, delete the tkb app and then you donāt need to worry about migration. I have done this myself with > 20 tkb devices over a months ago and had no issues at all.
Confirmative. Works without problems. Re-paired one TZ-67 dimmer switch within a few minutes and some extra minutes to recover some flows it was used in.
Not being certain how TKB dimmers work in terms of zwave command processing, I only have the on/off switches. But I just noticed that this work around might provide a problem with them, assuming they are listed as GENERIC_TYPE_SWITCH_MULTILEVEL.
Iām develloping a zwave device which uses this class. All goes well using a simple Homey app I created, but last days, when testing to include as simple zwave device I found out that the dim levels sent by the device via a Multilevel Switch Report are being mapped wrong by Homey. Positions 0-99 are mapped as 0-255 instead. So a level of 50% will be listed in Homey as roughly 20%.
Depending on how TKB implemented this or you implemented in flows, you may have never noticed this however. The device Iām working on sends its final position back as safe guard. The value of the slider representing this position thus doesnāt align with itās āasking positionā.
@Jonathan_Draper and @Torch1969, do you use the dimmers directly by the slider, or only in flows? Could you do me a favor and check what happens if directly set by the slider? Does the slider change position shortly after the dim level has changed?
Depends on what you call wrong, the 0-99 is done by 99% (if not more) of the z-wave manufacturers as that is what is specified in the Z-Wave specifications.
And there are 2 other used values, also in the specifications.
254 should be the previously used value
255 is position unknown
I only have simple on / off TKB devices Iām afraid so not able to help here
You are right and actually in line with what I wrote.
Let me try to clarify however what happens.
The device only sends values 0-99 as per command class specification. As per command class specification the values 100-253 are reserved and āMUST be ignored by a receiving nodeā. However, they are accepted by Homey and 0-255 are being translated to a 0-100% scale.
Sending 255 or 254 results in 100% in Homey, 253 in 99%, 99 provides 39% and sending 50 results in 20% etc.
Again, this only happens if included as simple zwave device. In a very basic app I set up a while ago this works just fine.
To add to this. I guess as 0-99 doesnāt directly translate to 0-100% as used by the slider, there seems to be a simple re-calculation built into Homey. Apparently everything above 50 is re-calculated minus 1. So actually 50 and 51 both are send out by Homey as 50. 52 is translated to 51 etc up to 100 which translates to 99. This I actually found out first during development. It seems understandable and a fine solution to me, since not a problem in practice.
I see for instance Eurotronic solved this 0-100% vs 0-99 mismatch in their Spirit by translating incoming value 99 to 100. You can check this one easily by sending 99% from homey and checking the display of the Spirit.
Again all fine as long as not included as simple zwave device. I dare not to test with Spirit as simple zwave device, since I have too many of them and even more accompanying flowsā¦
Hello Niels. I already noticed this strange behaviour. Iām using the slider once I a while and found it was kind of strange.
But with TKB home app itself it also has a limited range of the slider to control dim level. So maybe this issue isnāt addressed in that app also
Groet, Gert
It is even more simple then everything under 50 = 50 -1, everything is just either divided by, or multiplied by 99 depending on which way it is going:
to the device:
https://github.com/athombv/node-homey-zwavedriver/blob/master/lib/system/capabilities/dim/SWITCH_MULTILEVEL.js#L37
from the device:
https://github.com/athombv/node-homey-zwavedriver/blob/master/lib/system/capabilities/dim/SWITCH_MULTILEVEL.js#L48
99%+ apps use this very same build in dim capability/calculation as that is what the specifications says to do.
The generic z-wave device also just has the basic command class, which is a 0 - 99 specification, and also the generic z-wave ādeviceā uses the same calculation:
to the device:
https://github.com/athombv/node-homey-zwavedriver/blob/master/lib/system/capabilities/dim/BASIC.js#L9
from the device:
https://github.com/athombv/node-homey-zwavedriver/blob/master/lib/system/capabilities/dim/BASIC.js#L17
That TKB doesnāt want to follow the official specifications is just stupid (again) as it isnāt the first time where they do things different then they are supposed to.
Eurotronic now has a change in this with their new Comet 700 where the manual control of the valve range is from 0 - 255 as users wanted more control, instead of the older versions (all 3 previous z-wave models) where it was just following the normal specifications for Multilevel_Switch, which is 0 - 99 ( 0x00 - 0x64 ), also following the very same calculations.
Wow, thank you for this detailed answer!
Good to see how things are written down.
Again device class specification is nicely followed here and the only values the device will send to Homey are 0-99, 254 and 255, so unfortunately still no explenation for this behavior though.
Indeed the basic command class has the same specification. It is even mandatory for switch multilevel and has been implemented as such. However a Homey generic z-wave device doesnāt seem to imply it just uses the basic cc. It is listed in Homey with the command class specified by the device and I can see the values come in as such in the z-wave development board and z-wave zniffer.
Does a generic z-wave device also use the ZWaveDriver or does it use a different mode of mapping capabilities to z-wave command classes and v.v.? The device report values are somehow divided by 255 instead of 99ā¦
Thanks to @caseda I am now the developer for TKB Home. Iāve just released a test version supporting SDK3 here TKB Home | Homey
Please feel free to try it out and let me know of any issues. Please report issues at Issues Ā· pshotton/com.tkbhome Ā· GitHub
Thanks
5 Likes
Thanks for taking over!
I just re-added my two TZ67 Z-Wave Plus plugs and they are working flawlessly again.
