Close
0%
0%

Automated Living Project

This is the umbrella project that encompasses all the aspects of the integration of electronics into our every day lives.

Similar projects worth following
Overview of each element.

All parts of the project can be found by clicking here:

https://hackaday.io/projects?tag=JAW.HA

Master Project for automated living!

Central Server( OpenCV//TFTP Server/Fileserver/homebridge, voice API server) project:

https://hackaday.io/project/115168-automated-living-backend-server

Room Assistants:

https://hackaday.io/project/87226-room-assistant

Lighting / Fan Controller:

Thermostat/Damper Controller:

Security Controller:

https://hackaday.io/project/116886-securitycontact-server

Garage Controller:

RGB Lighting Controller:

Coffee Controller:

Inline 120v ac Relay Controller:

Car Integration:

https://hackaday.io/project/106789-automated-living-car-integration

I am using this as an excuse to get much better at documentation as well, Ill be documenting my FTW moments, and my failures!

Updated 2018/04/04

Added Security controller link

JAW.HA.pdf

A quick overview of the system

Adobe Portable Document Format - 97.11 kB - 04/12/2018 at 19:07

Preview
Download

  • Oh Life...

    James Wynhoff05/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 Wynhoff04/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 Wynhoff04/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 Wynhoff04/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

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates