This project consists of a protocol spec, the design files for physical nodes and the source code that glues it together.
Full protocol description is available, together with examples of a monitor and a sender. The protocol is text-based to ease debugging.
ClearSky technology inside: the basic concept is that no coordinator is needed for the nodes to work after the initial configuration. There must not be a single point of (catastrophic) failure. And obviously no "cloud" (hence ClearSky) service is needed either: you, and only you, decide if/when/which data can exit from your network!
The most critical element is currently the access point, that is so cheap that having a cold-standby one should not be a problem.
Messages must support authentication and encryption to guarantee that confidential packets or dangerous commands are actually sent from an authorized source.
Warning: protocol is still work in progress and unstable: non-backward-compatible changes are still possible! Only after 1.0.0 milestone changes that introduce incompatibilities will be delayed till 2.0.0 .
All HW designs were in KiCAD 4.0.x (will follow what's packaged in latest Ubuntu LTS) so not to require nonstandard installs. But 5.x introduced too many new features not to be used, and it's "easy enough" to install (official instructions).
DIN-rail mounted devices are designed for the 6-modules AK-DR-04C enclosure. Note: these enclosures won't fit in a standard DIN rail box, unless you can move the rail further from the front panel (like in Gewiss GW40030).
Other devices are designed to be compatible with Vimar Plana series, but should fit other series with minor adjustements.
In the given layouts I use KF2EDGK right-angle (KF-2P, KF-4P or KF-6P) 5.08mm (or 3.81mm) pitch connectors so I can detach the node from power without having exposed wires with dangerous voltage laying around (and can reconnect it quickly and safely). Be sure to buy the angled version or you'll have a lot of extra work to bend the pins!
Warning: I did my best to keep the costs down without sacrificing security. Choice of the power brick is really important for security: never use HLK-PM01 clones unless you know what you're doing -- and even then it's better to avoid using 'em! If in doubt buy directly from Hi-Link (sorry, plain http, not https...). Probably the boards can't pass CE certification only because of conducted emissions, but since I don't have access to test equipment use at your own risk (or have 'em certified).
SSRs and relays should always be sourced from reputable sources. If in doubt, do not load 'em near the limits. For example never try a 400W load on a 2A SSR -- use a servo-relay. 2A SSRs are good for a couple of LED lamps, or a 40W bulb.
DomoNode 1.1
A node based on ESP8266 to be mounted in a 6-modules DIN rail enclosure.
Provides 4 SSR outputs and an expansion bus connector.
[OSHW] IT000001 | Certified open source hardware
- The text for GPIO4 and GPIO5 are reversed in the ESP12 symbol.
DomoNode 2 2.1 (WIP)
Evolution of DomoNode, but offers 6 inputs @ 230V, 6 SSR 2A@230V (each one have its own independent in and out lines, for maximum flexibility) and 8 independent LEDs, still in a 6-modules DIN rail enclosure. Kept SW compatibility with basic DomoNode (just the first 4 outputs), but different external connections.
To better follow the norms, now inputs are on the top and outputs at the bottom.
Same expansion bus connector as the DomoNode 1.1.
I kept 2mm between L and N lines and it ought to be double-insulation, but it's actually not required: the user can't touch anything that is not already expected to be at 230V (screws in connectors) without opening the enclosure (the expansion connector MUST NOT be exposed).
The board requires two v-cuts around the central part, drawn on ECO2 layer (but not visible in the image). Once the two boards gets separated, the smaller one have to be mounted over the bigger one, using 2 M3x25mm plastic spacers and suitable 1x14 pins headers (I used 2 1x14 female headers on the boards and 1x14 male pin strip with 21mm long pins to connect the two headers).
Notes:
- Designed in KiCAD 5.1.5.
- You can probably omit C8 quite safely
- Use 1k for R15-R22 or D1-D8 will burn after some months of use
Changes from (deprecated) 2.0
- No glitches at powerup on outputs: all outputs are off until told otherwise by FW
- Uses PCA9555 instead of MCP23017 (smaller, cheaper and already used for other expanders = smaller code footprint)
- PCA9555 requires less components (pullups are included and outputs can directly drive SSRs)
- wider traces (6mils were really too thin)
- added socket for authentication chip (ATSHA204A or ATECC608A)
- slightly moved connectors to better fit enclosure; probably some extra cuts to better accomodate connectors will be required anyway
- replaced through-hole LEDs with SMD 0805 ones, better suited for light guides
- highlighted pin 1 side for SMD IC footprints
- corrected SDA and SCL pin assignment to use Wire.begin()
- reduced confusing level semantics: relays and LEDs are ON when writing a HIGH level to the port (required to keep compatibility with FW for DomoNode 1.1), inputs are active when reading a LOW level (can be inverted via PCA9555)
- used the PCB part with JLCPCB order number as a guide for LED holes: align "BASE" to the bottom of the concave part at the top of the box cover and use "LEDS CNTR" line to mark LEDs center line, then rotate the ruler and use markers on the short edges as a reference for the center line of the holes (the side opposite to "BASE" must be in contact with the right side of the concave part)
- includes (yet untested) lightguides design files, ready to be sent to laser cutting service (use 5mm transparent plexiglas)
- includes sample code (just add your FSM; webserver already accepts clicks on relay status to toggle it; config editing not yet implemented)
DomoNode-inout 1.1.1
An expansion node to be mounted in a 6-modules DIN rail enclosure.
Provides 4 SSR outputs, 3 220V opto-isolated inputs and 8 5V GPIOs.
Uses a PCA9555 for GPIOs and a 24C02 to store the expander config.
[OSHW] IT000002 | Certified open source hardware
DomoDisp 1.1
A node based on ESP8266 that provides physical user interface to the system. Uses a 1.8" ST7735 LCD color display and a rotative encoder. It is designed to be mounted either on the front of a DIN rail box, inside a 4-modules Vimar Plana frame -- other frames could work but are untested, or with the supplied enclosure in a 504 (4-modules) wall box.
Requires a 5V power source (possibly a DomoNode-inout, but a dedicated module with power and relay will be published as soon as it's ready).
Includes sample "lib" for reading the encoder (needs cleanup... there still are traces of experiments I did to read ESP's ADC from an interrupt routine).
The display can be managed by TFT_eSPI lib and works up to 27MHz (only 10MHz when testing on breadboard) -- remember to edit User_setup.h before compiling your sketch!
[OSHW] IT000003 | Certified open source hardware
- The text for GPIO4 and GPIO5 are reversed in the ESP12 symbol.
DomoDispV2 2.0
Future release using shared SPI bus for display, freeing 2 GPIOs. One of the freed GPIOs is used to control dimming.
WARNING: FW is incompatible with old DomoDisp!
DomoNode-inputs 1.0
WIP - Still untested !
An expansion board with 11 inputs @ 220V and 5 low-voltage IOs.
When inputs are powered from 220V they get read as logic low. Low-voltage inputs are directly connected to PCA9555 lines so there's a weak (100k) pullup active at powerup. If you want to use 'em as outputs remember to use inverted logic to avoid glitches at powerup.
DomoSwitch 1.0
WIP / On hold (I'd need to source a suitable front panel, first)
A node that hosts 2 relays (or SSRs -- double footprint), 2 pushbuttons and 2 RGB LEDs. Split in 3 sub-boards to fit behind a 2-modules Vimar Plana 14042 hole cover.
The buttons and LEDs are placed so that they match the markers inside the 14042 cover, simplifying the assemply.
To be compliant with SeeedFusion rules, I had to split the 3 sub boards as different designs. Then I simply combined the sub-boards to better use the 100x100mm area. That means that for $15 plus shipping I get 40 complete boards... I hope it doesn't require major mods!
TODO: support to enclose the dangerous sub-boards (I'll have to prototype it with a 3D printer, but will need a resin cast for the final version).
It's obviously possible to support 3rd-party devices like SonOff, Shelly, touch switches and so on. Reversing and further info is usually published first on my site (mostly Italian-only)
Still work in progress.
A sketch with partial protocol implementation is under test.
Expansions (DomoNode-inout, DomoNode-inputs) are autodetected and (mostly) autoconfigured by library. The algorithm is:
- for each I2C bus address from 0x50 to 0x57
- if slave found at 0x5X:
- determine memory size:
- try reading location 0-4 using 8-bit address (24LC02)
- try re-reading the same locations, still using 8-bit addresses
- both reads are equal => 8-bit addresses
- else
- set flag for 16-bit addresses
- read locations 0-4 using 16-bit address (that would overwrite location 0 in 8-bit devices, but we already ruled out this is a 8-bit one...)
- check first two bytes for 'magic' constant; if wrong, go to next address: not a device we can handle (possibly uninitialized)
- read device config from it
- determine memory size:
- if slave is not found at 0x5X, test if a slave is present at 0x2X
(PCA9555 in DomoNode-inout 1.0)
- if PCA9555 is found, create a fake config for 4 outs and 3 ins (TODO: how to handle other GPIOs?)
- instantiate the correct device class
- if slave found at 0x5X:
This algorithm assumes the memory have already been initialized. The EEPROM must contain at least these 16 bytes:
- 0x00 2 bytes 'magic' 0xD74A (0xD7 in 0x00 and 0x4A in 0x01)
- 0x02 1 byte Expansion type (Official "registry" is kept in lib sources)
- 0x03 1 byte Release code (every new HW release increments the release code)
- 0x04 4 bytes "unique" board ID
- 0x08 8 bytes reserved
The remaining space is used as defined by device class (usually for IO configuration and descriptions). The board ID must be "unique enough" so that the master node can detect that an expansion have been changed and invalidate the old mappings.
I added to the repository all the informations I found re: security chips that could be used w/o signing NDAs. The list is probably incomplete.
I'm currently working on ATECC608A, trying to reverse engineer the information that would require signing NDA (why, Microchip? WHY??? you opened the docs for the 508...)