The problem: the Loxone Access Controller and iButton
and it's flaws to be acceptable as a business solution
Loxone is a great system for integrating all functions of building management into a single app, and to control a mix of devices, all at a low cost. We have many small business customers (3 to 30 employees) that are happy with this single and fully integrated solution to manage their office building, including lighting, heating and AC, ip cam monitoring, burglar and fire protection, audio, VoIP phone integration. But one thing that they consistently ask for is a better Access Control system.
There are 2 parts to an Access Control system:
- control and automation of door locks and door openers: Loxone can easily control a mix of different types of door and gate systems directly without requiring a separate controller.
- access authorization: managing users, keys, and their access rights to different doors. Here is the part where Loxone is falling short.
These are the complaints:
- use of iButton: you need to make physical contact between the iButton and the iButton reader for a variable time often between 0.5 and 1 second. This puts you always in doubt wether it is making proper contact or not. People are used to swiping RFID tokens (keycards, keyfobs) in front of a reader and receiving inmmediate feedback confirming that the token has been read.
- no Access Management tool: to make any change, like assigning a new iButton to a user, or blocking a lost iButton, you must use the Loxone Config software to make the change in the configuration and re-upload it to the Miniserver. This is a complicated procedure which can only be done by the person who programs the whole configuration. One or more employees must be able to do simple user management like adding or removing tokens, while not being able to change anything else in the total configuration and without rebooting the Miniserver.
The solution: a new Access Controller in Loxone PicoC
accepting readers, keypads, fingerprint scanners
We already solved the problem of the iButton by replacing it with our RFID reader emulating and iButton. For a family home with just a few users that mostly do not change, this works well for up to 4 doors on a single 1-wire extension. With more users, you should have 1-wire extension per door just to keep the configuration clear. Small businesses who only need to change access rights exceptionally can manage. e.g. creating spare keys upfront for guests or in case of loss.
However, people also ask us for different versions of the reader: smaller, design, build-in behind a plate, more secure, keypad, fingeprint scan, NFC. But when there is no Access Management tool to complete the system, it makes no sense to invest in that.
But we really do want a solution in Loxone, because:
- we don't want separate systems: other access control systems often cost over 500 euro per door, and require you to use separate software to manage users, and does not integrate well with Loxone. E.g. the Mobotix T25, which can do many things, can authorize RFIDs but can not send the authorized ID on to Loxone (a workaround would be to have Loxone read Mobotix' log file).
- we want access control to be tightly integrated, and not only open the door, but also disarm the burglar alarm, switch on the proper lights and audio, log-in VoIP phones, etc depending on the user.
- for monitoring your office or house, it is more useful to know who entered the building at what time, e.g. you can check remotely from the Loxone app whether your kids have come home from school.
- we want to use a single app to manage the complete building, so also the user management.
So here is our solution:
We replace the Access Controller functional block in Loxone Config with a Program block and write an Access Controller in PicoC that takes a UserID and DoorID as input. Theses IDs can come in via any of the protocols available to Loxone or any of it's extension (except for 1-wire), e.g IP, KNX, RS232, RS485. The script checks the user 's access rights and provides the results, incuding the user's name, via the outputs.
In it's simplest form, the user rights are stored in CSV files locally on the Miniserver. Changes to the files can be made from withhin the Loxone app or directly in the files (download,change,upload via FTP). Via the Loxone app, you can monitor all access requests and e.g. grant access to the last read ID to add a new token, or block the last read ID to remove it. The script can be extended with groups and time schedules.
There are all kinds of readers on the market that output the ID via RS232 so you can use any of these by adding a RS232 Extension per door.
The standard communication protocol however for most readers, keypads, etc. is Wiegand. Therefore we will program (and sell) a microcontroller (Arduino Ethernet to start with) to read any Wiegand code, and send it as a UserID, allong with a DoorID, over TCP/IP (UDP) to Loxone.
- configurable secure Mifare readers exist on the market and allow to store a shared key in both the tokens and the reader to use a custom secret code rather than the serial ID only. Configuration of the reader is done by writing the info on a Mifare token and presenting it to the reader.
- the access rights do not need to be stored in local files. Since we are using a PicoC script, we could as well request authorization from another system via IP, or write changed access rights to a remote system.
- the microcontroller will also read our 1-wire readers, so you only need 1 microcontroller for up to 4 doors.
- 2 Wiegand readers can connect on 1 microcontroller serving 2 doors independently
- a number of inputs and outputs will be available on the microcontroller which you can control from the Miniserver via IP, saving you I/Os or extensions (e.g. Input use: door status (open/closed), bell button, request to exit. Output use: access granted feedback for led or beeper, door lock relais)
- we only discuss/share/customize our PicoC script and Arduino program for free with our Loxone customers as we want to invest our time in helping our own customers and improving their solutions. We will sell complete and tested solutions. Anyone with some programming skills can build it themselves.
- why don't we build a complete access control system on a Raspberry PI? Because it is easier/simpler to have all configuration/programming/management in Loxone only. The script can easily be adapted to the customer's needs and can make use of other blocks and conditions e.g. a time schedule.
- why communication over IP: because you do not need extra Loxone Extensions. An IP network is available anywhere in most business locations, or can easily be provided via Wifi and client Access Points. Doors in remote offices can also be connected to the same Miniserver over the LAN-2-LAN VPN.
- you will be able to purchase a pre-programmed Arduino microcontroller from our webshop soon, when it has been properly tested and accepted by a customer. We will also offer a selection of tested readers and security devices as a bundled complete solution.