I just tried automatically adding one of these devices to my configuration via the openHAB ZigBee Binding (3.0.0). The scan discovers and appears to recognise the switch and allocates 2 channels, 1 for each gang. So far all well and good.
The problem is that when I switch it on, either manually or via the associated Items switch point, it automatically switches itself off after 2 minutes. If I delete the “Thing” then it appears to work as a normal light switch, not timing out after 2 minutes, when I re-bind it the problem reappears. So I am thinking that either the switch has a built in timer which is only activated when bound, or the “Item” has a hidden expire timer, in either case I would like to be able to disable, or significantly increase, the timeout. Has anyone come across this, or a similar problem and if so can you point me in ther direction of resolving it.
I’m not sure I can directly answer your questions, but I would say that in instances like this, the logs are your friend. If you check the events log for starters, that might help answer your question of where the timeout is coming from. If not, enable debug logging in the ZigBee binding to see if the binding is receiving a command from the framework, and sending it to the switch, or if the command is coming from the switch itself.
Once you know WHAT is happening, it will help you answer WHY, and then be able to do something about it (hopefully ).
Support for these Tuya-Switches is just being implemented within the ZigBee binding.
I tested the Betas from @schalli and it works fine.
Those Tuya devices talk a zigbee “dialect” that causes some trouble.
Interestingly, the vendor name is different for your switch.
Unfortunately, that means my change will not work as-is for you.
I am only matching certain vendor names (the ones I have), but I already figured they have a random suffix.
@chris, What would you suggest to address this? Regex vendor name matching or matching the model name only?
@Birchcroft, can you install custom binding versions? If so, I can package a version that should support your switch for testing.
@schalli At the moment I am only in the process of familiarising myself with OpenHAB and working on the specification of what I want to achieve. So I am more than willing to install custom Binding versions and perform testing if it helps the community.
Let’s see . I don’t know why this will help to be honest - if something is turning the switch off after 2 minutes, then I don’t think the changes in the binding will change this to be honest. Let’s see though
I would need to see how it’s implemented in the binding - we may also have to add multiple entries in the device list to point to the same thing definition. That would be the easiest and safest, but obviously carries the maintenance risk that there will be more variations out there (which of course is why I have tried to make the binding automatically detect devices rather than use these definition files - I wanted to avoid this - in the ZWave binding we end up supporting a database of around 1200 devices).
Yes @chris, you are right, this may not help.
But as we saw strange behaviour of those switches I thought it might be worth a try.
@Birchcroft:
Are you receiving an “OFF” message from the switch itself or is the target actor (The “Light”) reporting this?
What kind of actor for the actual light are you using ? Maybe there is a timer defined?
Absolutely - of course it is better to have this, and maybe it will magically solve the issue, but I suspect it won’t. To be honest, it would be nice to see the logs to understand what is going on as if it does magically go away, it would be useful to know why.
You might have picked up from other posts - I like to understand why things are happening. Often we see people say “I did X, and it started working, and therefore that was the problem” - often this is wrong. We see “I reverted to an older binding, and it works, so the new binding is faulty” - even though there has been no change. Later we’ll find the old binding didn’t work either, and it was an issue with routing, or an errant rule that was doing something strange etc…
So, I think getting logs to understand what is happening is an important thing to do. If you don’t know WHAT is happening, then it’s really impossible to say if it is fixed.
The situation was that the switch was being operated either by (1) the physical switch; (2) the UI via the Equipment Switch Point. In both cases the switch automatically switched off after 2 minutes. The only thing recorded in the standard log was the state change. I tried adding an expire timer to send an ON command every 1:45 but this did not solve the issue and led to some odd behaviour with what appeared to be some crosstalk between the two switches. When non-bound to the ZigBee controller the switch works correctly, i.e. the light comes on when you turn it on and does not go off untill you turn it off.
At the moment I am unable to provide any further detail from the logs as I have just installed the Beta version of the driver. Once everything is up and running I will let you know how things are going.
Just to let thank everyone for their help, especially @schalli, but I’ve now decided to put the switch in a draw and spend my time more profitably on other aspects of the system and finding an alternative switch. The reason for this is that the manufacture has confirmed that the switch only works with their hub/App which needs an Internet connection whereas I want a single automation solution independent of the Web/proprietary solutions where you are potentially impacted by the whims of corporate policy. Even so I have still learnt a lot and benefited from your help (@schalli, @chris, @Oggerschummer) as I start on my Openhab journey.
).
