How we built a Smart Office system based on Raspberry Pi
monterail.com
monterail.com
> The light control set up is fail-safe. If something with the RPi goes terribly wrong, we could still operate the lights in the “classic” analog way.
(I wish they'd explained how they do it, but I assume they use latching relays to switch the actual lights, so RPis and light switches can work in parallel)
Using the chrome debugging protocol for the remote screens is also quite clever.
From there all you need is two (or more) diodes to handle multiple pulse inputs. Some pulse relays even have diodes built-in (i.e. can handle multiple inputs from the get-go).
You can easily spot this sort of installation - wall-mounted light switches only go one way, and return to original position as soon as let go. And each press changes on/off state - sort of how Caps Lock works.
Note, however, that switching voltages/currents higher than rated will likely shorten the life of your relay.
Also, solution for jamming relays are SSRs. In practice there were issues only with two biggest light zones with multiple lamps switched at the same time.
[0]: https://knx.org
Also the term open is very relative here (you have to pay a fee (1000 euro + VAT last time I checked) to access the standard, naturally there are no redistribution rights, KNX certification process is order of magnitude more expensive.
You need a closed source configuration software to be able to configure the devices. Runs only on Windows (XP did it last time but things may have been changed). A single licence costs 1000 euro + VAT, unless you use limited version that works up to 20 devices and costs 100 euro + VAT (in many small cases that would be enough as the limitation is project based).
PS. It is rather an attempt to put things into a contexts than a criticism.
Minimum setup:
1) KNX power supply (provides power for the KNX bus),
2) KNX actuator (relay or dimmer or special (say LED stripe)),
3) KNX switch (or an input device (can use standard wall spring switches)),
4) KNX bus connector for programming (USB tongle, KNX/IP router, there are many options),
5) KNX configuration software,
6) Windows machine (VM works too).
This setup allows to map the actuator and switch in the configuration software and upload the configuration into the devices.
Please also note that encrypted communication between KNX devices is commonly not supported (but so is it also for a simple pulse signal from the wall switch to the relay).
Took me a little while to find out what is was actually about on the website, most pages contains just marketing speak.
I wonder if there is any other (really) open standard that could be useful to follow in DIY systems.
Future modifications and changes will be easy even with support discontinuation from our side. Every part of the system is modular - you can pull out RPi with custom modules and place any PLC instead.
You practically never pay the 1000€ because it is owned by the company putting the cables in your home. But, yes, you have this software fee if you want to change the hardware on a regular basis (but I must say, I don't know anybody doing this).
Sorry, but no. The reason to DIY is that you can continue to maintain it properly as you go along.
I don't think I've ever used or worked on a project with PLC's handling any sort of core logic though. Sure they'll occasionally run small components of simple edge systems (HVAC, lift motor control, physical access etc) but the overwhelming majority of systems are built with a network of embedded controllers. Any systems rolling out today will (or at least should) then combine this with some server side backend for analytics and shifting interaction logic away from the the edge systems to somewhere it's a little easier to change and adapt to the needs of the building.
There's some pretty established, older players (Crestron, AMX et al) that make full programmable solutions, but by all modern standards their development tools are atrocious - you'd need to be a complete and utter masochist to want to enter that world today.
The good thing about this is a bunch of amazing people building well designed, open source and non-proprietary solutions to make this world suck less.
My two favourites are http://nodel.io/, which runs a fully distributed architecture (and can even have the nodes running of RPi's) and http://www.acaprojects.com/ which is a keeps all the system logic server side.
I'm very much into open-source, so thank you for those two solutions. I haven't seen it before.
In any case, I sure hope they have mounted their SD cards as read-only, because otherwise they might find their keycard system not working one early morning in approximately a year or 2-3 random power off events. Theres a reason for these PLC systems after all.
Also, I would not have thought that random power off events would affect modern file systems as poorly as you're suggesting.
Interesting thoughts though.
https://learn.adafruit.com/external-drive-as-raspberry-pi-ro...
I've thought about the idea of having some super-capacitor based temporary power storage, and an interrupt that triggers a graceful shutdown if the power input goes down. I think it could be done with fairly basic circuitry.
For most <1 day outages, a simple USB power-bank with passthrough capability (output whilst also possibly charging) will happily keep the pi going, but without some frankenbodging there's no 'power lost' signal that the pi can sense. I've idly toyed with the idea of a phototransistor on the powerbank status LED and an attiny or something.
Now that I think about it, there was someone trying to make a supercap idea, but I don't think it went anywhere: https://www.indiegogo.com/projects/juice4halt-supercapacitor...
You can also echo a magic sysrq key (eg-"b") to /proc/sysrq-trigger. "e i s u o" would do the full graceful shutdown. This nicely asks processes to quit, kills (almost) everything, halts the system, syncs disks, and remounts fs ro before going down.
Or you could create a service with systemd to (run a script to) check when dbus gets a particular signal, like a network device being added or removed if an SSID disappearing was your indicator of power loss, then halt.
I'd probably just plug them into a UPS, though. Just have it send one of the shutdowns to the "master" when running battery power for longer than a few minutes.
Unfortunately, it's been over a year.
I tested power-off events many times - there were no issues at all. At last, keycard failure won't be a crucial issue, there is a parallel intercom connected with reception - our front-desk manager can open the door wirelessly.
I'm of the same opinion. But the Pis come with HDMI and audio-out which is convenient to plug TVs and speakers to. At least for the TV outputs, one could use ChromeCast, but you'd have to figure out a solution for multiple audio outputs. Would a single beefy Linux PC support several USB audio outputs?
To my eyes this shows really you care about what you build.
Nice job!
I wonder how they handle security. Especially since it also controls access to the facility.
Also, would be pretty funny if the RPis went all Hall one day.
In case of sytem failure almost all parts has alternative working conditions: lights can be controlled with wall switches, rfid lock can be programmed separatly, etc.