This page describes the general concepts in hardware and device firmware design, common to all hardware parts built for this project. Other documents such as interface standards or part pages are linked from here where neccessary as soon as they exist.
The CAN bus itself is explained in detail on external web pages. A starting point may be Wikipedia.
The bus will be routed through all rooms to be controlled by the system as Cat.5e standard cable with RJ-45 connectors for the bus device attachment. The actual pin assignment can be seen in the bus device documentation. This wiring makes it somewhat difficult to add bus devices after the initial installation, because the cable then has to be split up and the new device inserted. However, I expect to address this successfully by leaving some extra cable in the installation that could later be used for such device addition splices.
The main interaction with input and output devices, takes place in few switch panels: One in the basement, next to the central electric switchboard (where also all fuses for the house are located), and three in the ground floor: One for the right part of the house (controlling the combined living and dining room, the kitchen, kitchen storage, small restroom, and the hall), one for the left part (for outside lighting at the main entrance, both home office rooms, bathroom, bedroom, and corridor), and one located in the outside storage room, controlling that room, garden, and garden entrance area. This way, the cabling from the central electric switchboard is reduced to trunks up to the respective switch panel. Data cabling, which is out of the scope of this project, will still need a central patch panel, though.
This power cabling, in turn, mandates that the CAN bus also has an attachment point in each of the electric switch panels, with the respective devices attached to the input and output devices in the rooms those panels control.
For attachment of simple on-off or momentary contact switches, 12V DC signals will be used. These will be optically isolated from the microelectronics reading switch state. Power output will be controlled by electromagnetic or electronic switches and dimmers, available as COTS versions with all required regulation authority certifications.
All devices attached to the bus support a common set of features to ease operation and maintenance.
An overview of bus devices (and associated standard definitions) can be found in the Parts listing
If neccessary, the firmware running on bus devices can be updated through the CAN bus attachment while the rest of the infrastructure remains operational. Operation of the bus device being updated may not be guaranteed during the download of new firmware, and will be interrupted while the received new firmware image is being programmed into the device.
Bus devices handling I/O attachments monitor the functionality of the attached devices as far as this is possible without too much technical or resource overhead. For example, a momentary switch that constantly signals activity may have mechanically latched to the "closed" state and can be reported being defective (or at least requiring a physical checkup).
The bus devices also monitor their CAN bus interface and collect respective error statistics. These can be requested by and reported to the control station.
CAN devices need a unique bus address by which they can be identified when sending messages to the bus, or when CAN remote frames are to be directed to them. Furthermore, a device may require basic configuration, such as designation of I/O lines as momentary or steady-state input, or grouping them to evaluate multiple signal lines from a value input device (like "value up", "value down", "enter"). For this basic configuration before becoming an active bus device, all CAN-attached parts include an UART interface on which, through a standardized protocol, a configuration handset can be connected.
All devices are classified according to their capabilities, and the device class is made known to the control station by means of manual configuration or automatic detection on bus attachment, where this makes sense. Light switches, for example, will need manual configuration according to their location before they can do any operation within the system, a temperature sensor could already transmit values before manual configuration is required.
For each device class to be included and managed in the system, a specialized software module is used on the control station.
For certain operations, direct interaction between input and output devices makes sense. For example, if there is a pushbutton controlling a single output (or even a group of outputs), the respective output controller can toggle its output state when it recognizes the pushbutton has been activated (i.e. it has seen such a message on the bus). Here, the control station only needs to recognize that there was a state change, and that this has been acted upon. Therefore, it is possible for the control station to program (according to its configuration) certain simple direct actions into the output devices, such as "if input X has been activated, toggle output Y".
It is still possible that a certain output shall be deactivated regardless of input activity (e.g. for maintenance purposes). For this case, the direct actions are designed to be configurable at runtime.
to be described