This page last changed on Oct 22, 2013 by garfield.arbuckle.
I am experiencing a very annoying issue.
My house is full with ABB 6127/02-500 Touchsensors.
However lately they have the habbit of going into some sort of sleep mode (they all have the same issue).
So what happens is that the Touchsensor looks completely normal, the leds are on and everything looks fine.
However when you push one of the buttons nothing happens. When you push the button again the function behind it is executed without any issues.
You can now try 100 times more and every time the button will work fine. It just seems like the touchsensor goes into some sort of sleep mode and pushing a button wakes it up again.
The Touchsensor is used together with the 6120/12-101 bus coupler.
The Touchsensors have quite some functionality, like storing lightscenes etc. However when the Touchsensor is in this "sleep" mode these lightscenes are also not executed.
For instance I have a light sensor which triggers a 0 bit on a group address which needs to be inverted to a 1. I use the inversion functionality in one of my Touchsensor to do this however when the Touchsensor is in "sleep" mode it doesn't execute the inversion.
So I hear you think, what does OR have to do with this.
Well, I'm trying to figure out if OR is in any way involved with this.
Last week I took OR down for a whole week and I did not have the issue however the issue occurs purely random and not on a daily basis.
This week I brought OR back up and I've been experiencing the issue again.
If anyone has any idea what this could be please let me know.
I honestly have no idea how to troubleshoot this one, so any tips in that department would be very helpful too.
But if you have no problems when OR is down then why putting it on at all? I think that I'm missing here something.
Posted by aktur at Oct 22, 2013 16:32
When OR is off I don't have any visualization.
I use OR as the glue between all the interactive bits and pieces within my home.
So turning off OR is not really an option.
Posted by garfield.arbuckle at Oct 22, 2013 23:39
At OR startup we sent a host of group read requests to every device to fetch their initial state so we can display the correct values in the UI. This is the only thing I can imagine could somehow impact your actuators. But this is just a normal read request. After that we are not interested in communicating with your actuators unless you send a command to them. We are simply listening to the data indications your devices are sending to the KNX bus.
Number of commands sent to KNX bus depends on your configuration. Press buttons on the panels but also your rules.
The only slightly suspect part of the initial state fetch is that it's done in a burst immediately at start. The larger the install the bigger the burst.
Do you still get the same behavior if your running OR without any of your own rules? To rule out the impact of rules.
With regards to the burst behavior at startup, we could have some configuration options to throttle it. Anything that throttles it however increases the delay that your panel UI may be out of sync with the actuator state. This option is something we can try if nothing else seems to solve it but it requires code changes so it's not something you can try immediately right now, and I don't yet know when I will have a chance to investigate implementing such a patch.
Also, what kind of datapoint type do your touch sensors use?
Posted by juha at Oct 23, 2013 09:59
It are not the actuators(dimmers or switchers) which are having the issue but the touchsensors, so the buttons on the wall.
It's all brand new ABB equipment so it should be able to handle the read requests at startup.
I also can't find any correlation between starting OR and the issue, so it's not like when I start OR that I will immediately see the problem.
If OR generates a lot of traffic at the start of OR I would see the issue immediately.
In addition to this OR would poll the actuators for their state and not the touchsensors. Having said this I have no foolproof evidence that the actuators are not involved however I'm quite sure they are because of the following reason:
Lightsensor Detects Day/Night ---------> Touchsensor with internal programming to trigger lightscene --------> Lightscene triggers switch actuator and blind actuator.
When the touchsensor goes into "sleep" mode the lightscene is not triggered so both the lights haven't turned on nor have the blinds moved. If the issue would for instance be in the switch actuator the lights would not have gone on but the blinds would have moved. So that's the reason why I believe the issue is in the touchsensors.
I will try your suggestion of removing my rules from OR and let you know.
The touchsensors can use several types of datapoints. Most of them are just 1 bit on and off or 1 byte dimming. Some of them use a 1 byte.
Cheers and thanks
Posted by garfield.arbuckle at Oct 23, 2013 10:19
Just two quick questions,
1. how do you use your wall switches, is it let say Right for ON and Left for OFF so each 4 gang switch controls 4 light circuits or do you use them as toggle thus having 8 functions for a 4 gang switch??
2. Do these switches have a separate object to update their led indicator status ??
Posted by stavroschar at Nov 01, 2013 16:17
1) Right ON, Left OFF so indeed 4 gang switch controls 4 light circuits.
2) Yes they have.
Posted by garfield.arbuckle at Nov 02, 2013 00:07
I've had a bit of time today to do some more investigation and I found the following.
When the touchsensor has crashed (is in sleep mode) and I push the button it does send out a frame on the bus when I push it. However it sends out a bad frame according to ETS.
When one button has been pushed and this bad frame has been sent, another push and all consecutive pushes will work just fine.
Anyone any idea, anyone seen this before?
Posted by garfield.arbuckle at Nov 02, 2013 00:12
Well, at 10 bytes those are partial frames for sure. It looks like it might be an end of a CEMI frame with some data bytes going out to seven separate group address destinations from source address 0/7/3 but that's a pretty much just a random guess, it could be anything really.
Posted by juha at Nov 04, 2013 15:33
Ended up being a software bug.
The good people of ABB came by to upgrade the buscouplers and it should be fixed now.
Posted by garfield.arbuckle at Nov 08, 2013 14:56