I have 2 IKEA symfonisk control “knobs” and have successfully added one to the zigbee binding (the other is still in the box).
In theory it supports a dimmer channel and act as a toggle switch as well with 1,2 and 3 presses.
Current case: Only a dimmer channel is identified.
In the logs I can see the command in cluster 0006 (onoff) and 0008 (Level control).
The issues are the followings:
level control: the linked channel runs to max or min within a very small move range (knob rotation cca 30-40 degrees), which is not really essential in any use case. How could this behavior be normalized? (200-250 degrees or greater)
onoff: as written above, there is no channel discovered for this, but in the logs the appropriate cluster can be identified when pressed, but only for a single press. How could I capture the button presses? (Once it can be captured there should be no issue to create a rule to cover 1/2/3 presses)
Many thanks for the quick reply.
Right now I am facing to a different issue, as all my battery devices were drained.
In this case this one and an ikea motion sensor, but some months ago it happened to me the same w an Ikea remote, the battery became empty just in few (4-5) days.
So I replaced the battery in the symfonisk, but it did not react to anything any longer.
Removed from OH, then added/paired again, but except for the discovery, I see no kind of activity at all. I let the gadgets rest a bit and in the morning I give another try.
About the logs: it seems like I can provide debug logs beginning from 17th of July (that is the approximate date of installing the accessory).
Do you need all or just the last couple of days?
I guess it would be good to see if there is any regular communications from the binding to the device - there shouldn’t be. So just a debug log showing 10 or so minutes with nothing happening - if there really is nothing happening, then alls good
I’m not sure what device is the battery device? There are a log of command received from 180F, but the binding isn’t requesting this information. In general the binding isn’t sending a lot - the log runs for about 7 1/2 hours, and there are only 127 commands sent in this time as far as I see from a quick look - most of these are sent in response to OTA requests (which is something lightbulbs often do), and there is a new device added to the network it seems which generates most of the data.
So the network looks pretty lightly loaded and certainly the binding is not doing very much that should impact any devices sleep patterns.
The first several hours was after I added the device, the single dimmer channel was discovered, but then the device remained offline and whatever I pressed or rotated did not wake up. After this 7 and 1/2 hours I woke up (successfully) and added the device again.
Only 3 zigbee plugs and this Zigbee device are paired in this moment.
Thanks. So again the binding isn’t going to impact the battery life here - while the device is sleeping, the binding isn’t sending anything. Even if it does, the device is sleeping so it will not receive it.
It will be the plugs that are sending the OTA messages, but again the binding isn’t really doing a lot in this log. The plugs will be looking for new firmware updates - this is quite common with mains devices, but again the binding is just responding to messages from the devices.
Maybe the best thing is for you to monitor the logs to see if you see anything that looks suspicious and then ask here and I can look at this?
Ok, sorry. I thought that the logs here were relating to the battery issue raised above? So to be clear then, with these logs, what is the problem that you are showing? The lack of on-off channel and commands being too sensitive?
If I go back to your original question then -:
You need to check the device manual. The binding can only respond to the commands it has. Maybe the device has a way to change sensitivity?
If there is a level control and an on-off cluster, then you will not get an on off channel - only a level control channel. This is normal - you do not need both (this is how OH works).
The log was requested by Bruce right after my initial post.
What I am trying to show:
there is a toggle/onoff
there is a move updown
What I would like to understand:
toggle: is there a way to implement a channel for it or if not, how to capture it
dimmer: perhaps the payload is something like not standard and so does not behave the dimmer as intended. Is there a way to change it to reach from min to max (and max to min) not that quickly? I saw there are some speed related contents in the messages when rotating to any direction.
I requested the log to assist @chris in troubleshooting. He is the Zigbee expert. I do not even use that binding at this time, but I use hos excellent Z-Wave binding.
No - the payload is standard. If the device sends it too fast then I don’t think the binding can change this, but maybe there is a configuration that can be changed in the device?
I think you should read the device manual - it’s not really a binding question I think? I’m not familiar with this device, but we are talking about the messages that the device sends, and not the way that the binding interprets them aren’t we?
I’m not sure what you refer to?
There is a “rate” parameter that can be sent - maybe that’s what you mean? This is the rate at which the device asks the other device to move from one level to the next. The binding doesn’t interpret this though since OH has no way to handle this. However that doesn’t change the rate at which the device sends commands - if it sends a level of 10,11,12,13,etc, very quickly, then the binding will interpret these level commands as they come in.
ok, understood, what I did not get is if i can build a rule on that or is this a complete dead end?
I have no problem with making a workaround with rules if viable
I think too, but it is IKEA… place the battery, pair, close the cover, put it on the wall, enjoy (if you can)
yes i meant this. Ok, so this obviously a dead end.
Can these messages be processed with a rule, if yes, I can put some effort on it to make a workaround.
I don’t think so - at least there is nothing specific about the toggle - you only get On/Off.
Ok, then I guess it can’t be changed. I will take a look at the ZigBee standard to see if there is anything specified there.
I’m not sure - you will just get the level information as you are getting now so I think it’s hard to try and change the speed given the raw data from the device is the problem. The rate information is probably irrelevant if the device is sending commands super fast as the underlying issue is the device sending data too fast.
Knowing it is a toggle, I can interpret it on my “stupid” way… if that message can be captured/processed, can’t it? I do not mind if there is no official solution, but I would be said to buy something like raspbeeII just to have it working.
No problem if no official solution exists, here I could build my own ugly rule too
I was thinking about (again: if I could capture and use the data) to pick the move ups and downs (as I saw that in the message that is sent and not the dimming level… hopefully I did not miss a crucial thing), ignore if within xy milliseconds the same move is sent and then tadaaaaa, slow down succeeded.
To sum it up, if all works as intended and there is no official way to enhance, for both of the things (toggle and dimmer) what is needed to be able to process the data in rules. Is that somehow possible?
Do not misunderstand me, I am not asking you or anyone to write rules, I would do it on my own.
Yes, I guess if you know that it is only ever a toggle, then you should be able to use this. However there is no way to differentiate a toggle command from an on/off command in a rule.
