Project Logs

Collapse

• Oh Life...

  James Wynhoff • 05/11/2018 at 16:25 • 0 comments

  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!

• More Module Definitions

  James Wynhoff • 04/12/2018 at 19:14 • 0 comments

  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!

• ​The birth of an API...

  James Wynhoff • 04/09/2018 at 09:02 • 0 comments

  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]"}

• Reuse of old electronics.....

  James Wynhoff • 04/04/2018 at 20:44 • 0 comments

  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.

View all 4 project logs