I have been away for a bit, we bought a new car, and our baby is just about here!

Sadly this project didn't get picked for the first round of the 2018 HAD prize, but this is still something that is moving forward!

Ill have 500k can bus dumps on the mobile assistant project soon!

I am about 60% of the way through what I want to call the stable boilerplate for the ESP based devices, and based on feedback the modules that a JAW.HA device can adopt are now as follows

IOSERVER

LIGHTSENSOR

TEMPSENSOR

HUMIDITYSENSOR

LIGHTCONTROLLER

FANSPEED

SHADE

MOTION

SECURITY

LOCKCONTROLLER

THERMOSTAT

GARAGECONTROLLER (instead of using the default IOSERVER)

APPLIANCE

CONTROLLER

BACKEND

BRIDGE.ALEXA

BRIDGE.GOOGLE

BRIDGE.APPLE

I will be testing the first of these devices shortly!

And the reasoning behind some of my decisions.....

My goal with this project is to have a whole suite of devices that expose their control in an easy to use way.
I took a bit of inspiration from can bus design, some devices just announce what’s happening to them, and you can chose to listen to it, or just ignore it. Then you have commands that are targeted from 1 device directly to another, and once again, we can listen to this, or ignore it because it isn’t meant for us.
We will be broadcasting when a device comes online and available on the control port broadcast, and we will also transmit a beacon on this port.
Anything to do with device announcements and configuration should happen on this port.

The control port should announce the current status of all aspects of the device when it comes online. It will announce all status changes for masters to listen to. It will also respond to group commands for the type of device it represents, and targeted commands sent to the device.

The thing I like most about this design is that we can also number every message coming from each device so that even though it’s UDP, if we have a master listening to all the traffic it can respond and request any missing info.

The rest of this post is mostly just me writing down my current thoughts on this API I am proposing.

UDP Broadcast port 24000: Management

Command Format:

{"EVENT":"ADD","SerialNumer":"0000ff112233","CurrentIdx":101,"productDescriptor":"IOSERVER","VARS":"INPUTS(8);OUTPUTS(8)"}

EVENT: ADD/REMOVE

SerialNumber: unique identifier for the device

CurrentIdx: the current index being used from the device

productDescriptor: anyone one of the defined descriptors available

IOSERVER,LIGHTSENSOR,TEMPSENSOR,HUMIDITYSENSOR,LIGHT,FANSPEED,SHADE,MOTION,SECURITY,LOCKCONTROLLER,THERMOSTAT

VARS: product specific variables, usually the count.

REMOVE *serial*

To signal a resource going offline:

{"EVENT":"REMOVE","SerialNumer":"0000ff112233"}

UDP Broadcast port 24001: Device data

An update from a device would look like the following:

{"EVENT":"UPDATE","SerialNumer":"0000ff112233","Index":305,"productDescriptor":"IOSERVER","VARS":"INPUTS(8)=[1,1,1,1,0,0,0,0];OUTPUTS(8)=[1,0,1,0,1,0,1,0]"}

Index: the current message index for that device, all messages are sequential

{"EVENT":"COMMAND","SerialNumer":"0000ff112233","Index":312,"productDescriptor":"IOSERVER","VARS":"OUTPUT()=[1,1,1,1,0,0,0,0]"}

{"EVENT":"COMMAND","SerialNumer":"0000ff112233","Index":355,"productDescriptor":"IOSERVER","VARS":"OUTPUT(2)=[1]"}

I end up collecting, among many other things, old hardware, sometimes its a piece of hardware we really wanted to use in a project, sometimes its the being replaced by a newer fancier piece of equipment, and sometimes the only reason it failed in the first place was because of just a simple blown cap.

There are several pieces I have been holding for several years to finally make use of in my new house, and with the goal of getting all this incredible data, or ease of using an off the shelf product to satisfy the needs for the project, over the last few days I have been trying to get some of these products up and running for use...

The first one is the powerhouse dynamics emonitor12:

It has input on it for 24 CT inputs. What a great and easy way to start monitoring my power usage at the house right!

Well, to use this thing you have to pay a license fee every year to let it upload data to the cloud, but I don't want THEIR cloud, I want to be in control of my hardware, and my data...

Credit where credit is due though, I was already in product selection to roll my own board, and looking at this board gave me a few insights:

At its heart is a Lattice LFE2-12E, a pretty nice FPGA!

They offloaded the ethernet to a Rabbit RCM5750 module

Both of which have programming headers on the board, and they are populated!

The way they sample the CTs is what I thought was really interesting

they are using an (74hct4051d) 8>1 multiplexer(3) to get the 24 CT inputs down to 3 outputs from 3 banks of 8 CTs,  the address selection lines, 3 of them, got to the FPGA.

The output is fed to a dual channel op-amp (max4477), and finally to an Audio A/D Converter(Cirrus CS5341) that outputs i2s to the FPGA...... wait, what?

I can honestly say I had not thought of this design! But wait, 24 channels/8/2 is 1.5 ADC chips, where is the last input coming from?

The 12v AC feed gets its voltage dropped and fed into the last channel, I'm ASSuming that's how they are doing ZC (zero cross) detection.

More to come soon, as well as pretty pictures.