> 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.
Hey! I was happy to be designing this beauty (and using it everyday in our office). It's nothing more than just a "stair switch" configuration, where one of the manual switches was substituted with a relay. So we have all SPDT manual switches on the walls, and SPDT relays connected with them in our control cabinet. Every switch/relay can change state of the receiver (in this case a LED lamp) at any time. So even if relays or RPIs fail we can still be using manual switches. More info here https://goo.gl/sJw9F1 .
From what I understood looking at the photos in the article, "relays" are some fancy-looking external box. It is quite possible that those are "pulse relays", i.e. RPi sends a short voltage pulse to switch relay on, then another short pulse over the same wire to switch off.
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.
I have Rpis controlling my various plant-grow-lamps around the house; the relays they switch are set to fail-open so if they fall over I can go back to manual control; so you probably assume correctly. Now if the relays themselves get sad I'd probably be in for a bad time but fixing that seems like a reduction problem? (I speak as someone clueless about actual EE beyond treating it like legos)
Most relays are rated for a "number of switches", usually in the few hundreds-of-thousands for both mechanical and SSDs. If you switch twice a day (on/off), you've got a few hundred years.
Note, however, that switching voltages/currents higher than rated will likely shorten the life of your relay.
I don't know what kind of relays you're using, but most relays tend to fail in a closed position, so it's worth considering what happens if a light is turned on continuously. Also, hardware or software failure in the RPi could turn on all of the lights in your house, e.g., if the same software running on every unit encounters a bug.
And for those cases I decided to place wall switches in parallel. As automation fails you can still operate all lights with classic, wall switch, way.
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.
A DIY-solution is nice (and as engineers something really fun to do) but they will have to maintain it in the future and this is not necessarily "future proof". They would have simply put some KNX[0] compatible components in the system, they would have had control of everything using an open standard. They could have connect light, security cams, door locks, the power plugs, etc... and because this is a standard, the day they move out of the office, they will be able to resell the system to the next users.
KNX would be definitely a choice but you have to be careful and shop around as many KNX manufactures are known to be incredibly greedy. The situation has improved a lot in recent years though.
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).
Thank you for this clarification. I was interested when the parent mentioned KNX as a standard for these types of setup, but quite disappointed to realise it was another of these "open standards with high barrier of entry".
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.
Exactly. Price level of our system is incomparable with same solution based on KNX.
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.
The first configuration is pretty simple and the 1000€ license is just to "build" the elements into your office/house. Once they are setup, you do not need the license and can control everything with fully open source software. The hardware is now easy to buy and not that expensive at all[0].
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).
We both agree, but my point was more to think "future safe". You do not rebuild your house/office every 12 months like some people are rebuilding their app with every new framework coming out on the market.
Yay, this is my world! Looks like a super nice homebrew solution.
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.
Yeah, even stuff like Niagra is a pain. Most solutions are configurable more so than programmable (in the scripting sense). I've done a fair amount of modbus and bacnet with "standard" systems and more pi-style systems and agree that for a developer-minded user it can be like gazing into the mouth of madness to work with.
I'm surprised all they found were PLC based solutions. I worked in lighting and building controls for years and most products used embedded systems and not PLCs.
Hey, you're totally right. Actually we would normally use some embedded solution for that (preferably STM32 or ESP8266 if wireless was needed), however, in this case we were focusing on designing it in a way so that it's easy to maintain by web-development agency, which we are. Not everyone here knows how to change and flash low-level code into a uC but almost everyone would be able to fix a bug in python code on the RPi :)
That's like saying "How we built a Smart Office system based on Electricity", the RPi is just any old single board computer here with some GPIOs.
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.
There's something else. The RPi is prone to failure if it's writing to the SD card when power goes down. Articles that I've read suggest moving most of the RPi's files to some other form of storage, for instance:
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.
such things exist (such as the pico from http://pimodules.com/) but I've had nothing but grief from its firmware using v1 and v2. There appears to be a new version, and I suppose it might be better now.
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.
Could you not simply have a 5V DC power adapter on the same mains line, and detect if it is on or off via one of the GPIO pins? Is that considered frankenbodging?
That's what I would do. The loss of 5 V on the GPIO pin triggers a interrupt, which forces a graceful shutdown. As I understand it, there's a command which halts disk access, which is mainly what's needed for a graceful shutdown.
You can use "systemctl poweroff", /sbin/shutdown, "shutdown -Ph now" (in case of wonky ACPI), and a few others to gracefully halt.
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.
If you lose power on an RPi, it'll sometimes put everything in a state where it won't boot again. I've had this happen often enough at my parents' place in India (the power goes out unpredictably there) that I just imaged a bunch of SD cards and left them there so they can just swap it out when the time comes.
I am running a Raspberry Pi hosted web server for almost 4 years now. I only changed hardware to newer Raspberry Pi and bigger SD card after first 2 years. Never had any issues, never had to buy new SD card, its still up and running 24/7.
SD cards are in normal operation mode, besides of one card failure after one month (some factory defect I suppose), everything is fine. We will see when do the life cycle of cards expire, a year is behind us.
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.
> That's like saying "How we built a Smart Office system based on Electricity"
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?
As an experiment, I set up the four outputs of my computer to play a different audio stream simultaneously. Each one took about 1% cpu usage. Next I played 5 videos simultaneously, streamed from a hard disk drive. I only used two monitors there, but that was about 4% CPU usage per video. My computer is admittedly kinda beefy, but I have no doubts that a slower computer wouldn't have trouble with the task.
Thanks for asking! I can explain you how the lighting unit works since I was taking part in designing it (better than nothing :) ). Since we didn't have enough GPIOs on the Raspberry which is controlling the lights, we used a GPIO expanders (MCP23017 https://goo.gl/S4i9Gw). RPi sends commands over I2C interface to switch their outputs on and off. MCPs outputs are driving optocouplers (on the same PCBs designed by us) to provide a proper level of isolation. Then the optocouplers' outputs drive the relays working in a "stair case" configuration with analog switches on the walls (see a my comment above and here https://goo.gl/sJw9F1). All the "low-level" software is written in python using ready to go libraries and exposing API to a web-app which is basically a user interface for the system. If you need more details, just shoot!
Relay modules from finder, custom pcb modules with current outputs for switching relays and optoisolators for voltage detecion, some custom expansion module for all signals interconnection. I will prepare some appendix to the blog-post with more technical data.
I'd love to see more details on that. The RPi is the easy choice for putting together a DIY system at home, but finding good and affordable remote I/O modules to run the show has not been that straightforward.
RPi is only accessible in separate local network. Doors also has regular locks which are used after working hours.
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.
Last time I tried, webkit for RPi leaks memory after playing audio for a few hours. It would be great to have a follow up post after the system is in production use for a while.
We designed our own, simple ones having MCP23017 (https://goo.gl/S4i9Gw) as the GPIO expanders and some popular optocouplers to provide proper isolation level. I can't remember which exact part was chosen for the isolator, but this one should work like a charm https://goo.gl/GS6twt.
> 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.