KNX pushbuttons dying

Hardware Home Automation
1

Hi,

Calling out local knx experts.. @Udo_Hartmann :slight_smile:
I know its not related to OH, but I dont have any clue about good knx forum in english, so this is my safe place to cry for help :slight_smile:
I have tried posting on schneider-electric knx forum, but that is not very active and very very slow (each post and reply has to be moderator approved and it takes days).
The only reply I managed to get is that my PSU might be failing, so devices are running out of power/misbehaving. They advised me to measure the voltage, which I did and got 30.3VDC stable voltage on the bus. So i guess its not that.
Here is the issue:

in my condo i have the following knx setup:
1X Merten actuator (7 lights), 1X Merten dimmer (4 lights), 2X Woertz Fan Coil Actuator (HVAC), 3X SchneiderElectric Wall Controller Pushbutton MTN6214-4146 (8 buttons), 7X SchneiderElectric Wall Controller Pushbutton MTN6212-4060 (6 buttons), 1X Merten PowerSupply 160mA. On top of the originally built setup, I add ESYLUX USB KNX gateway.

Recently two MTN6212 wall controllers stopped working with the following behavior:
Once I press any button, the blue status led switches off for random amount of time, nothing happens with the lights. Sometimes if i press the button again, the status led goes back on. But sometimes status led is dead. Then if I use another wall pushbutton that controls the same lights, then the faulty one’s status led goes back on. When light is switched on via another pushbutton or via mobile phone, the “dead” controllers show the status of the corresponding light as on. and off when light is off’ed via phone. so they are fine as read-only status panel to see what is off what is on, as long as you dont touch them.

Now, on top of that, some 2 other pushbutton controllers become unresponsive and slow. Takes them 2-5 seconds to switch on the light. If I power cycle the knx system via the power breaker, it kinda improves for a while.

On other controllers it works fine (instant). also software control (via usb knx gateway running knxd and openhab) works instant.

I got a suggestion to check PSU. I measured 30.3VDC on multiple points on the bus just to be sure. Seems stable. anything between 29-31V should be fine?
My PSU is 160mA, should I go for 320mA to be on the safe side?
In case one day I decide to replace my 10 pushbuttons with some more modern touchscreens I assume they will draw more power?

What could be the cause of these issues? is it possible that SE pushbuttons are dying one by one? what is the expected lifespan? these are about 15 years old. Openhab has been controlling the setup with no such issues for the last 5 years.

Maybe the faulty pushbutton causes havoc on the bus and makes other pushbuttons unresponsive/slow sometimes?
Anyone seen such behaviour?

TIA

2

I’m by no means an expert for knx hardware, so I can only guess… :slight_smile:

BUT… 15 devices connected to the bus and only 160 mA power source seems optimistic to me, at least you should calculate with 10 mA per device plus some headroom, so yes, 160 mA should suffice, but there is not much room left for degradation. Maybe you have a faulty connection somewhere on the bus?

The bus is never DC :slight_smile: because it’s only two wires for power and data, you can’t simply measure the DC voltage.

As a test you could cut some devices and check whether knx system starts working reliable again, but I guess you will miss each of the devices :slight_smile: so maybe, as a bigger power supply is already in the queue…

3

In theory, a bus device may draw 10mA, so you might be a bit close to your 160mA PSU.

But before replacing the PSU, I’d check the packets on the bus itself. When reading your post it seems, that you don’t have ETS software available (yet).

I’d recommend trying at least the ETS Demo with your USB interface. Use the “group monitor” to capture the packets on the bus to judge, if your controllers are sending out any telegram timely when pressing a button. Helpful of course is the knowledge of the physical bus adresses as well as the group adresses. The latter you know likely, otherwise you won’t be able to control your KNX stuff from openHAB side

4

One more thing: My installation is currently 20 years old. I’ve added quite some more bus devices during that time. Two Merten actors needed re-programming during that time as they suddenly lost some of their configuration (some channels worked while others not …).

The only real outage I had was … the power supply (from Merten as well). In my case it was a 320mA version. But my PSU was completely dead and likely not just degraded. I replaced it by a 640mA PSU with UPS support (still Merten/Schneider brand)

5

Not an expert, but have set up 2 houses with KNX so far.

I was surprised how little power do the devices need, when I bought from Kleinanzeigen an ABB power supply with power measurement and LED indicators for load, replacing a 640mA one without power measurement. Well… I just started ETS to check. About 40 wall switches of which about 12 have an always-on status LED, 6 big actuators, wind/light sensor, interface for ventilation system, Ethernet interface, a binary interface for the radio control for the garage door and lights, and they currently draw… 178mA.

If I were you, I’d try removing the wall switches from where they are and connecting them temporarily on some short wires right next to the power supply or actuators. If they work correctly there, then the problem is the old KNX wiring in the walls, or actually the contacts between wires have corroded over time and developed resistance. If the KNX buttons show the same symptoms, then they might be deffective.

6

Thanks for replies and suggestions everyone!

I have ETS but I didn’t feel that I will be able to get any meaningful conclusions with it, as it seems more like some hardware//wiring/power fault. But will fire it up anyway and see what happens when I touch the faulty buttons (and yes of course i know the addresses of devices as I configured OH).

I also don’t believe 160mA is underpowered as whoever designed it was probably doing the power sizing calculations as there is 1500 knx apartments in this compound (which all work for 15 years with no power issues), let’s say about 30% are identical setup as mine. The buildings are 15 years old, so I also doubt wiring had gone bad/corroded, but who knows….

If there was PSU degradation, voltage drops, then I guess I should get random issues with random devices, not always same 2 wall controllers…

I will probably end up either disconnecting some devices, or removing the problematic button from the wall and testing it on a short cable as you suggest.

If it turns out wall controllers are really dead, I will ignore it for now because I mostly use openhab anyway, actually lights are mostly automated so I dont really need that many wall switches :slight_smile:

I just hope the health of the knx setup will not continue to deteriorate, wall switches are one thing, but if I lose an actuator or a dimmer its not fun…

7

My sister’s house suffered a water leak just a few weeks ago, with water running for hours from the ground floor into the basement, where it was around 10cm deep.

Some of this water passed through the concrete floor and then through the network closet, where it went into the network switches and covered the circuits with a thick crust of concrete powder.

Water also passed through the MDT IP interface, where it caused a different result: even with the low voltage, the circuit board, pins and wires corroded into a blue foam, to the point where one of the power pins has been completely cut off by electricity and remained stuck in the WAGO connector.

image
image672Ă—673 45.6 KB

Something similar happened to a wall button panel where sufficient humidity built up: the board and circuits corroded.

image
image684Ă—660 86.7 KB

Looks like humidity paired with low DC voltage can have a very interesting electrolysis-like effect.

The point is: if any connectors in your walls were exposed to some intense humidity over the years, it could be that your physical bus is suffering from a similar fate.

8

Interesting, we do have high humidity during the summer but ac is keeping it under control indoors. However i popped the button controller out from the wall as I was curious now that you mentioned humidity. Everything is clean, device looks brand new from the back side, good contact, no discoloration…

9

Makes sense to narrow down.

Well, the group monitor capturing feature gives you the insight you need to find out, if the controllers are sending something when pressing the buttons, or more precisely: If those packets can be received at the point in the bus where the USB interface is connected. Just put the physical address of the device you’re playing with into the filter condition to omit packets from other sources if needed to avoid “unwanted noise” if any in that small setup.

Anyway: Please keep posting the outcome here as it is always helpful to learn from other’s investigations and especially from the results :wink:

10

dissolved-pins
dissolved-pins684Ă—660 135 KB

Crazy, it looks like even the whole connectors on the IC/µC have been completely dissolved by that oxidation (the turquoise color indicates copper oxides) and/or the electrolysis you suspect. Irreparable… :frowning:

11

Not to forget that the bus cable going through walls probably has some junctions in hidden connection boxes where it branches out towards multiple rooms or in-wall boxes. Those are the weak points where contact resistance can develop over time between copper wires and connectors, and which might need to be inspected, especially if you find that the devices themselves work fine on a short cable branching out from the actuators/power supply in the electrical cabinet.

12

I’m not sure it has hidden junctions, considering its a fairly small setup in a fairly small space (1550sq ft 2 bedroom condo) that has false ceiling all around so I can actually see and inspect all wiring, electrical and plumbing together with HVAC, water heaters, UTP network blah blah, its like another parallel apartment up there, engineering room attic :slight_smile:

Central KNX cabinet is in the hallway that is in the middle of the apartment, and knx controllers only go to the 3 rooms (bedrooms and living room). All other utility rooms, toilets, kitchen are knx free. so the knx cables are just running directly towards them.

Sure thing, will keep the thread updated with my findings.

1 Like
13

so, here are the results:

ETS bus monitor shows nothing is sent when buttons are pressed on the 2 problematic controllers (expected, otherwise, why wouldn’t light go on/off)

Then I have swapped around 2 controllers places. One that works in the bedroom with the dead one in the hall. The dead one continued to be dead, the working one continued working. So, this proves wiring is fine as another device works in that place, and we can conclude the problematic device is indeed dead.

thanks everyone for help!

for reference, I’m attaching the problematic Merten/Schneider Electric pushbutton.

If you can, avoid it like the plague. 2/10 dead under 15 years.

merten buttons
merten buttons1200Ă—1600 55.6 KB

1 Like
14

Don’t give up too early.

Do you have the full parametrization available for that device in your ETS project? If so, try re-programming the controller. Maybe set the physical address again and then write the application program again to it.

I do have some old 8/12 way rail mounted actors which lost their programming partially as I wrote already in a former post.

Simple re-programming fixed it for years now. Not a good sign of health though - but it worked. Meanwhile I bought replacement hardware waiting on the shelf until the suspect devices fail finally…

15

Hi,

That is a great advice and could probably solve it, and definitively worth a shot, but:

  1. Unfortunately, none of us living here has ETS project file, it was just not handed over. TBH, most people here never heard of KNX, nor do they have any IP gateway or any way to control it via software, as the setup came without any home server solution.

So when I wanted to configure openhab, I had to manually “reverse engineer” the setup, meaning pressing each and every button while running bus monitor and writing down each and every light, dimmer, HVAC, then monitor and correlate the data that comes to the bus without pressing anything, like room temperatures….fun.

There is an addon for ETS called Reconstruction that allegedly can sniff around the bus and pick up devices configurations, so I was planning to give that a shot when I will have free time…

But this would help me with remaining devices that are operational, it would create backup of their configuration, for future cases of dying and replacing them.

  1. I don’t have any experience programming KNX devices. So, I am not sure I would fully understand what am I looking at, would I be able to understand which device is what, those wall controllers all have unique combination of lights and scenes they control, so I in theory I could recognize what is what based on the button configuration.

But for the 2 that are not operational, I’m not sure if that tool would detect them at all and how would I find them, their address?

Out of curiosity, lets pretend this problematic button controller is brand new and I want to start configuring it from scratch, what would be the procedure, how can I detect it on the bus and program it? because, realistically I have nothing to lose even if I configure it wrong and brick it, its not working anyway, so it might be worth a shot.

or If I decide to indeed replace it with a new one, does it come with some default factory address, or ets just detects it and then you recognize this address is completely different from your other devices so you conclude that is the new device? or how you approach to configure it?

16

Well, it’s bit hard to “teach” KNX basic procedures via forum posts of course. Best is to start with some web based KNX training published somewhere on Youtube or by some of the manufacturers. Or even attend some free web trainings of the KNX association.

But in short, assuming a brand new device (or one you’d like to reprogram):

  1. Set the physical address of that device.
    This is a unique triple of <area>.<line>.<device>. Notice: “.” (dots) between the numbers.
    Assuming area and line being zero, a valid device address could be eg. 0.0.10.
    Check you bus monitor output to learn about your area and line. So you can conclude the right values for it.
    To set the physical address a bus device has a (sometimes hidden) button descripted with “prog”, this needs to be pressed and then the physical address program procedure can be started from ETS. Once done, ETS is able to talk to the device for further programming actions.
  2. set parameters of your devices (depends on the device) eg:
    • should a button act as a switch/dimmer control/rollershutter control etc.
    • control procedures one button/two button for up/down for rollershutters or dimmers
    • timing setting etc
      As I said, this is device depended but I find it mainly self-explanatory usually.
  3. Assign group addresses to the communication objects of your device. If you have sniffed some of the working controllers, you can roughly learn, how this is intended. Group addresses (GA) are somewhat like multicasts in other networks: One or more other bus member listen and act on the values sent to a GA. You already know about your relevant GA’s as you use them in openHAB.
    Different to physical adresses, GA’s have slash “/” as separator eg. 1/3/20.
  4. Once done, you can start application programming to your “new” device.

I’d again fire up the bus monitor to learn about your setup (physical addresses, group addresses) to conclude a free PA. If your installer did a good job, then you may find the used PA written on a sticker of your controller. So can re-use the old PA when re-gramming.

And regarding the potentially hidden “prog”-button. I’ve seen this on wall switches similar to yours: The “prog”-button was hidden by the transparent label cover (and the inserted label). So I had to remove the cover first to get access to the prog button.

EDIT: The “prog”-button is clearly visible on the backside near the KNX terminal.

The datasheet or application manual of your controllers should explain, how to set the device in “prog”-mode.

Hope that helps a bit…

EDIT: https://www.youtube.com/watch?v=\\\\\\\\\\\\\\\_hkLqgek2_c
(hands-on starts at aprx. 25 min)

17

thanks, it helps a lot of course!

Meanwhile I’ve made massive progress in understanding my setup a bit better.

I’ve run a line scan, my devices are 1.5.1 to 1.5.14. then I have collected individual device info and saved them as xml (the one that has serial number, running application version etc)

I even managed to read line voltage as 30.5 from some of the devices.

Then by using bus monitor and common sense, I managed to understand which device is what and renamed my exported xml files with the line address and description of the device.

Now, annoying part is I have 2 dead pushbuttons and 2 about to die! So out of 7 of the same model with 6 buttons, 4 are problematic. Other 3 are bigger with 8 buttons which control also AC, luckily they are doing fine for now.

Observations on the 2 completely dead:

  • they are not detectable on the line, but it’s clear what their address was supposed to be based on the missing holes in the numbers between 1 to 14
  • bus monitor show bunch of empty messages when buttons are pressed
  • the empty messages have only 1 value in Rout Type column Immediate_FC, Immediate_FA,BC,etc.. this is where you see GroupValueWrite for example

(I guess last time I used group monitor not bus monitor so I didnt catch those. also now I am connected directly to usb, and before I was using ETS via knxd.)

Observations on the 2 about to die

  • One of them works but after 15 seconds! (initially I thought its dead)
  • the other works after 2-3 seconds…

bus monitor show bunch of empty messages and then invalid frame (marked red) and then finally message arrives and lights switches on.

I would like to try to reprogram one of the completely dead…

Under ETS device catalog I found Merten 3gang push button plus. serial number, order number and application version match my device so I guess I can use that “template” or however its called while programming it?

Before starting programming I would like to see the configuration on one of my working buttons just so I understand how and what needs to be configured…

While exporting device details, i got this:

Group Communication
Item Value Resource name Unformatted value 
Address Table Load State Loaded GroupAddressTableLoadStatus 1 
Association Table Load State Loaded GroupAssociationTableLoadStatus 1 
Obj#0 (1 bit, -WCT--, Low) 1/5/1     
Obj#1 (4 bit, -WCT--, Low) 1/5/2     
Obj#2 (1 bit, -WC---, Low) 1/5/3     
Obj#3 (1 bit, -WCT--, Low) 1/5/4     
Obj#5 (1 bit, -WC---, Low) 1/5/5     
Obj#6 (1 bit, -WCT--, Low) 1/5/6     
Obj#8 (1 bit, -WC---, Low) 1/5/7     
Obj#9 (1 Byte, -WCT--, Low) 1/5/9     
Obj#12 (1 Byte, -WCT--, Low) 1/5/9     
Obj#15 (1 Byte, -WCT--, Low) 1/5/9     
Obj#29 (1 Byte, -WC---, Low) 1/5/9     
Obj#30 (1 Byte, -WCTU-, Low) 1/5/11     
Obj#31 (1 bit, -WCTU-, Low) 1/5/4     
Obj#32 (1 bit, -WCTU-, Low) 1/5/20     
Obj#34 (1 bit, -WCTU-, Low) 1/5/43     
Obj#36 (2 Byte, -WCTU-, Low) 1/5/45

Will this information be enough, I mean during the programming I will be asked to fill those fields with options?

I find it very bizarre that now 60% of my small pushbuttons are crappinig out. I think one of them crapped out now when i powered down / up / down /up the knx bus to swap around the controllers and test and revert back. Is it possible that power cycling breaks them or they lose configuration? I mean in 15 years they probably survived quite a few power cuts.

thanks again and my apologies to OH forum members un-interested in this off topic KNX matters, but I guess you can just ignore this topic….

18

You are on good way to understand and derive the needed information.

Though, your (currently) dead sensors quite likely need different GA’s assigned, as they are likely controlling different stuff…certainly mainly stuff in the same room where the sensor is installed. You said, that you have the GA’s available since you are using them from openHAB. So, when you adopt your GA’s to the right ones for that room you can give it a try. But even with the “wrong” GA’s you would find out, wether or not you were able to unbrick your controllers. Fixing the GA assignment later is then just fun to see everything to start working again.

Good luck!

19

great news is that the last one crapping out came to its senses, so now it falls to the group “about to die”, and I managed to harvest its configuration. it takes him 10 seconds to switch on the light, and during device scan ETS fails to detect it, but then you press a button to wake him up and voila, ets reads the device. so basically you have to massage it :slight_smile:

So I have 1 truly dead, 3 crapping out and slow,

About GA’s, yes exactly my thinking, the dead controller in the hall is kind of not that important, it controls stuff that other nearby controllers are doing as well. even if I configure it with wrong GA and it does something else, it will still be a great success if it works, and I can fix assignments later After I pass that proof of concept I can play with other 3 that are slow.

While I have you here, are you maybe familiar with the following bug:

lets say you have buttons for light1,light2,light3, and all off.

if you switch off the light1 on light1 button, all good. if you switch it off via all off, next time it doesnt want to switch on when you press light1, you have to press it twice.

Some time ago I managed to find a really nice explanation why this happens and how to fix it.

Basically the person who designed the system misconfigured it.

And I managed to lose the link to that solution. At that time I was not ready to tackle reprogramming of knx devices because I didnt have any major issues, but now it would be good to look into it :slight_smile:

Are you maybe familiar with the phenomena? I dont remember even what to google, maybe some return channel or god knows what…

20

Well, that’s an easy one:

According to your explanation, your buttons are in toggle mode: first click => “ON” next click “OFF”. This is controlled via the individual GA of that light. If a second button on another controller is using the same GA for that light - all fine: The first controller listens to that GA as well and changes its state accordingly.

If you have such “All off” GA’s all actor channel get this GA’s assigned additionally. Means: They listen to the individual GA’s as well as to the “All off” GA.

Guess what: Your sensory (buttons) must do the same. They need to get the “All off” GA as addionally listening GA assigned to adjust the last state accordingly. That’ all :slight_smile:

1 Like