Thanks for a great answer!
Is it a crazy idea to do with it an ambient light for home cinema 
? Something like Philips Ambilight?
The best prevention is what I wrote above, sturdy doors and windows. Since your security requirements seem quite high, I would say go with a stand-alone, power-fail and sabotage safe system and a certified company, as they will know how to best place all the elements for perimeter surveillance (detecting the intrusion attempt when it is happening) and motion sensors (detecting the intruder when he is already in). When you say “prevention”, I suppose you mean the first, rather than detecting an intruder already inside.
In addition to a siren belonging to the alarm, you can have it send a message to you home automation to make additional fuzz, but then that’s just the cherry on the cake.
Btw, if you want anyone to be scared even before trying, you need to make sure that at least some elements of your security system, usually cameras, are clearly visible from the outside. Where I live burglary is quite a bit more common than in Europe; they even sell dummy cameras, meaning just the housing of the cam, to make a house seem protected.
Not at all. Personally, I always set the lighting mood accordingly to what’s on screen.
Actually, some expensive Philips TV come with a system called ambilight, where they have a large number of RGB LEDs around the frame, shining back on the wall. However, other than a room lighting system, these are individually controlled by the TV according to what’s on the screen and react very fast.
Just setting the mood, that’s maybe a few LED strips behind the TV and illuminating the ceiling, is still well doable with KNX, but I personally have come to like the capabilities of the system so much that I do not think I would go to back to a lighting system not capable of color temperature/color.
The only point is the price: in case of KNX you’ll be hit by the costs in the beginning, but then the lights if they fail (and they will), they will cost you few bucks, but for Hue the initial costs are maybe not that high, but after replacing dozens of bulbs may get to the point where you would have KNX for it. That’s of course a great simplification, because I don’t know the costs, however it seems to be something that needs to be taken into account on a design-level.
I may be old and stuff, but if I learned something that is: don’t look at the price first (and only).
I know it’s hard if it’s the first time you’re planning a house… But imagine sitting in your living room, getting to bed at the evening, making yourself ready for the day, … In short: try to imagine, what you would like to have! Don’t let yourself go with gadgets and think in functionality only. “I’d like to see, that all lights are off, all windows are closed,… before I go to bed or leave the house” or “I don’t want to have to maintain three different systems for light, outlets and my blinds”, …
Take your time and write it down. Not technically in sketches, but in writing. If you know Scrum, write epics and user stories and fill your product backlog. After you have written down your requirements, try to build an architecture around them. I know, as a technical person we tend to take software and functions and use that as a start. But: you and your family have to live in it… 
Yes, let your wife write requirements also. Sometimes they will collide with your initial thoughts.
The price tag comes early enough. If planned intelligent, you can start with an MVP and build more modules later on…
I have no limitations. You can pass hardware through to the container easily with the --device=/dev/ttyUSB0 option (using the path to your device of course). I’ve no experience with Xen; I use ESXi. I did have a little trouble with ESXi 6.5 as their USB drivers were a little half baked and I couldn’t get reliable connectivity between my USB zwave controller and my VM. But I downgraded the USB drivers and it has been running without a hitch for over a year now I think. I don’t know if newer versions of ESXi continue to have this problem.
Though passing the USB device through to the VM and Docker container is not necessarily required. Particularly if the location of your server is not ideal for wireless communication with the Zwave or Zigbee mesh networks or the like you can use Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide with a cheap SBC like a RPi 0W to plug your USB dongle into and connect the device to your VM over TCP/IP.
And you do a thorough code review of the tens of thousands of lines of code that goes into a Slackware upgrade?
“No battle plan ever survives contact with the enemy.” - Helmuth von Moltke the Elder
You need to get real experience with these technologies before you can develop your design and plans. The wish list is a great place to start but if you start with a bill of materials and detailed architecture and plans before you actually have any experience with any of these technologies and systems you are almost guaranteed to make some very costly mistakes.You need to be doing tests and prototypes NOW while you are developing your plans and architectures. If you wait it will be too late. Each of these have edge cases and limitations that you will not be able to discover until you actually start using them.
Most solutions I’ve seen are to have AC to 5V DC converters in the rooms. So the main power is SC but at the outlets you have some 5V DC outlets. At least that is how some of my outlets work. Amazon.com I’m not sure if Lucky is referring to something similar.
Just be aware that smart bulbs are incompatible with traditional wall switches. If you have a regular old wall switch and flip it off the bulb goes offline. You would have to wire up “smart” switches that don’t actually control the power to the bulb but just turns them on and off.
For this reason (and the fact that I don’t care about color) I use switches and outlets that I can control, not bulbs.
Yep, but that’s also true for the dumb bulb version in KNX, the wall “switches” are programmable sensors that only send commands to the actors mounted in the switchboard. For KNX, if you want a manual off, you need to go to the switchboard (or just install an traditional one in the line and make everyone swear to never touch it).
Actually, this is a difference KNX vs. Smart: the smart ones can be turned off and on with a wall switch, and come up with a neutral white. A KNX installation does not allow that, because the power is switched by the actor on the switchboard, so when off an additional wall-switch has no effect.
Did you ever experience a KNX installation? What you proposing is just dead wrong!
Every 240v KNX device (in our case a bulb) needs at least a separate phase to the actuator, which is usually in the switchboard. The KNX bus cable runs to the place you would normally place “traditional” switches. The touch/switch sensor there can be programmed and it will send a command on the bus. The actuator now switches/dims/changes colour of the bulb.
Sure, if you cut the 240v in the switchboard or place a “traditional” switch in between, the bulb won’t get power. But that’s … WILD …if installed that way.
Sorry, that’s the sentence I forgot to remove after having written the second para, where it is expressed correctly.
Since you keep mentioning that: Can you point me to an actor that works with bulbs, and what bulbs? As I wrote, so far I was only aware of color changing actors for LED strips, and I would be really interested if a more versatile KNX implementation existed.
Still makes no sense. The actuator, which gets the OFF command cuts the power just as a “traditional” switch would do. No difference - except you can adress the actuator via the bus and therefore can automate it.
Sure, I use mostly GIRA and that’s the dimming actuator, which I use. It can be programmed to recognize the kind of bulb you’re using (e.g. Edison or led) and switch and dim accordingly.
https://katalog.gira.de/en_UK/datenblatt.html?id=658701
I frankly fail to see the difference between your words and mine as quoted here:
“the wall “switches” are programmable sensors that only send commands to the actors mounted in the switchboard.”
and then there
+++
edit Argh, again I missed a sentence here:
“the power is switched by the actor on the switchboard”
+++
And yes, if you want a direct, manual, hard, no-bus, no-logic-in-between no-fail off-switch, you have to go to the actor and trigger the channel there
No, it can only dim it, but you wrote there would be a color changing actor for bulbs.
KNX is industrial grade, certified fail-prove in itself. I never heard of a KNX bus failure ever. And my electrician installs them weekly in commercial grade environments.
Oh. I don’t use it, but here is one:
http://www.mdt.de/EN_LED_Controller.html
My electrician used some DALI in conjunction with KNX, which appears to be the “old” way. But as I don’t like and use it, I didn’t follow up on both.
I think you’re still confused by KNX logic. Pressing the button on the actuator itself is something I never ever have done - it’s pointless. The actuator IS in fact the equivalent of a “traditional” switch. The only difference is, it is not at the same place as the touch/switch sensor is placed. as the power is cut exactly the same way - only you need more phases as in a traditional setup, where you could theoretically have one phase for your whole house…
That’s one of the ones I was aware of. It has low voltage A-B-C-D-GND output and is not suitable for standard socket bulbs or otherwise contained lighting units, only for LED strips where you have direct access to the pins. The only way KNX can currently control color in RGBW lights other than LED strips is by a bridge to another system that has logic in the bulb/light unit itself. There are Hue bridges for KNX.
On the rest, I think we agree conceptually, I am quite well aware how that works, and you are obviously, too, but I am afraid I cannot find the point where we misread each other, so I suppose we just fail to find the right words.
My point is that also in a KNX system a switching action is triggered by a logical command, and therefore
In fact even more so than a Hue system, because the latter would at least react as expected, i.e. on/off, just be robbed of its logic.
that’s correct as socket bulbs are technically not able to receive colour changing other than wireless, so yes, you’ll always need bridges for them.
“traditional” switches have no place in KNX installations. Rich wanted to stress this, I guess as the TO wanted some “traditional” dimming switches in the first post.
… but TO is already convinced this is not going to work 
.
1 Like