DMX and OpenHAB Design Question

I am planing to renovate an old house.
Electric wiring has to be done new from scratch.

I am thinking about a combination of openhHAB, KNX for the sensors and DMX as light actor for most cases.
OpenHAB should make the home smart f.e. like turning the light on at night with only 30% and only every second light.

Since the WAF is the basic requirement, it is mandatory that a light switch turns on the light even if openHAB is offline or has are issues. So this will be done with knx directly.

BUT:

If the light is turned on by knx directly (family group address)
how can openHAB somehow overrule this command with commands like “turn the light on with 30% only”?

Is there an easy trick to check in the background if openHAB is the master for everything and
only if there is the problem knx should use the “basic setup”? something like a status variable?

How did you guys solve this?

I don’t really understand your question.
Since you cannot send commands from KNX to DMX, openHAB ALWAYS is the master, it’ll have to convert KNX commands/readings to DMX commands. If OH is down this cannot work unless you plan for having some other KNX server (but that is clearly not recommended - it’ll result in all sorts of synchronization trouble).

Either way, you should rethink your technology choices. KNX is expensive especially for sensors, and DMX isn’t all too popular for (home) lighting, most people would go ZWave or ZigBee instead.
I use direct wiring (switch and light are connected to the same actuator) where possible. The advantage is that directly wired lights will even work in case of a KNX or DMX bus or ZigBee outage (plus of course when OH is down. Since you redo your electrics anyway you should make it a star topology so this type of connection will be possible for your case.

Note that since a openHAB or KNX bus outage is pretty rare (assuming you did a proper job in setting up your server) and shouldn’t take all too long to recover from (assuming you did a proper job in setting up backup), we’re just talking about an emergency case. You don’t need sensors-triggered or group commands/scenes to work in this case; you don’t even have to have this in place for all lights (one per room should do).

Well, there are knx dmx gateways, so it would be possible to build up a system doing that without openHAB :wink:

There are some options.

  • Use knx logic module to delegate GA to other GA, but only if some GA is set to true. But this will end in a mass of logic modules, I think.
  • Use internal options of the knx dmx gateway (but only if there are options)
  • Override the knx command when openHAB is active

The latter option would be something like this:

  1. knx switch is sending its command to the knx dmx gateway.
  2. The gateway starts to set the lights.
  3. openHAB also receives the command and sends another command to the knx dmx gateway.
  4. The gateway cancels the first command and starts the actual command.

This option is also helpful if using knx dimmers with default brightness setup and a motion detector. To use another brightness level in the night, simply send the new brightness when receiving the ON command. If openHAB is stale, the dimmer will use the default level, if openHAB is online, the dimmer will use the openHAB level.

Thank You Markus for your Reply. I am using Zigbee and others with openHAB since a long time. Most of the time very stable.

Anyway for my own House I would like to switch to cable solution. If I did my maths correctly the KNX will not be to expensive (but not as cheap as xiaomi), since they will allow multiple purposes with one sensor.

Thank you Udo, that gave me a clue on how it could be done.

If it would be my own decision I would probably go with openHAB only for the logic.
But there was this one time were openHAB died with my wife at home and I was on a weekend trip :slight_smile:

So its either the knx dmx gateway solution with a lot of logic
or
maybe better and cheaper to have a fail over strategy for openHAB

Lets see.
For the next 2-4 months it will be cables, wall boxes and a lot of dirt.
Afterwards the fun part starts :wink:

Maybe I wasn’t very clear in this point :wink:

The third option would be to use a knx-dmx gateway, but to override the commands with openHAB. So you would only need the knx dmx gateway in addition to the other knx and dmx stuff (about 250EUR) but you will get a fail safe (related to openHAB) solution.

There is no way to get exactly the same behavior with and without openHAB (until you use openHAB only as a dumb UI).
Of course there are ways to harden openHAB.
If using a Raspberry 3B+, buy two of them. Connect both, configure both to boot over network, store everything on a NAS. If one Raspberry fails, boot the other (this would be cold standby, and it can be achieved in a women compatible way :wink: so only switch which Raspberry should boot). Of course the NAS has also to be redundant…
Another option would be to virtualize openHAB. it’s possible to build an automatic failover system with at least 3 computers for virtualization. Well, it would be like cracking a nut with a sledgehammer (mit Kanonen auf Spatzen schießen), but this failover system could be used to serve all sort of other stuff.

ATM I own two systems, the first (core i5, 32GByte, xen virtualizer) serves files, net printing, boot over network (with complete setup for both windows and linux and offline update for windows machines), an asterisk telephone system with soft fax option, a calibre server, a music server, a video server, an internal email server, some virtual windows machines for managing knx and so on, and two instances of openHAB (the second is the test system).
The second computer (hp MicroProliant Gen8, 16Gbyte, proxmox) is to backup relevant files every hour, and to serve some additional machines. This is my upcoming platform and it’s also used for testing.
My future plan is to use up to three proxmox machines plus freenas as a nas with zfs. This will be a lot of fun… :wink:

Yes, and that you need anyway.
See https://github.com/openhab/openhabian/blob/master/docs/openhabian-amanda.md