My Plans (OpenHab, Mac Sierra (Siri in whole house), Everything Run Native DC) Let the Fun Begin

Setup, Configuration and Use Beginners
1

UPDATED: This project has changed quite a lot from this original post. To follow project changes go to its primary Wiki on GitHub

GitHub Project Documentation:

Ok here is my plan need some pointers before getting off onto the wrong foot with a few of these things.

Every device will either run native DC or Propane (stoves, generator, etc.) I have already begun adding 12v lights to my new office and garage. My Macs, monitors, speakers (gotta find that humm), lights, everything is powered DC. I use 16 Channel 12v 30A Power Distribution Box 12v power supplies (30A) with 2A fused circuits (string some together if I need more than 2A). Solar panels and banks are coming, for now powering with AC:DC converters. Later will be native 48V main trunk in house with DC:DC regulators at each distribution box instead of AC:DC converters.

I have a few caseta wireless light switches in a few rooms that are still AC and a smart bridge pro (eventually hope to get rid of them when whole house is 12v).

We probably have 7 Macs around the house and untold iPhones, iPads, etc… (A big Mac family). Before any haters jump in, I’ve been a Systems Engineer for 30 years. I don’t mind fixing other peoples stuff (Windows), I just like mine to work when I get home. LOL :slight_smile:

So here is what I’m thinking, please jump in with recommendations.

I have one Mac Mini with SSD and 8g that is my main computer (Jarvis, NOT) I’m thinking AVA instead. :slight_smile: She is upgraded to Mac Sierra with a workaround to get Siri to voice activate to work. We have about 6 TVs all running Kodi powered by Mac Mini (a couple on Raspberry PI 3). All devices including lights, computers, monitors, outlets, etc will run through SainSmart 16 Channel Relay (10Amps/channel) with Raspberry PI 3 controlling each bank (maybe multiple banks).

I spend a lot of time and money on Adafruit, etc. building drones, for fun and precision agriculture mapping, etc… so I’m not afraid of a soldering gun and putting together custom sensors, etc. Built some basic ones using Pi Zeros and various components already. I’m just unschooled in OpenHab and while I love a good puzzle I need to jumpstart at least to a good selection of hardware to use for my scenario and protocols, etc.

My goal is to use OpenHab running on AVA (main Mac Mini) this will basically monitor and control the whole house, including 10 acres and tie into managing the solar setup coming. I hate to say it, but almost like a Jarvis (arrggh).

As backups to voice activation (which we all know still sucks), I was thinking in the old switch locations I replace them with pi zeros and a sainsmart single relays. Then I can have complete control either via Siri or manual switch backups.

Update: No need to put relays on pi zeros at the switch location. I can just have them sent an MQTT msg to the Broker and turn off the main relay in the distribution box. Saves cost on wires, relays and you can then put it anywhere!

I want this to be as all inclusive as possible and then some. So open source is important with a strong base following. I would prefer not to cloud any if possible. All contained locally.

Questions I have are:

Which is the best, most open protocol that also has some fair amount of stability and reliability to it?

Most of mine will be sending signals to remote PI 3s at distribution boxes to either turn on or off a relays. I will have the need for sensors, cameras, etc…

OH Yeah I have to keep in mind that I also do a lot of work with drones and often use very powerful transmitters (2W sometimes) in the 433MHz, 1.2GHz, 2.4GHz, 5GHz and 900Mhz ranges.

2

I’m not entirely sure what level of the networking stack you are talking, but if you are talking TCP/IP UDP Application Layer, MQTT is pretty rock solid, light weight, and has tons of libraries for pretty much all languages and platforms. It is pretty well supported in the HA domain as well.

If you are looking lower level or up a different stack I’m no help. I’m happy with my combination of wifi, zwave, and RFM69HW.

3

IP is my comfort zone by far. :slight_smile: So to clarify before I mix up terms. When you say Application layer to me I think of OSI Model. I assume there is a different structure in place for HA, boy I’m showing my noob status in HA. :slight_smile:

4

I am referring to the osi model, but was confused by your use of the word “protocol” followed by your concerns about radio interference.

There are all sorts of communications stacks used in HA.
Zwave and ZigBee are wireless mesh networks which bridge to openHAB through a USB controller. Note: ZigBee support in openHAB is in work and Zwave is a proprietary standard, though they are moving towards being more open thanks in no small part due to the work of this community.

There are a number of inexpensive devices which run on 433 MHz that people use which require a USB transceiver for openHAB to communicate with (I think).

Bluetooth is starting to be used more and more though support in openHAB is a bit rudimentary at the moment.

There are a number of devices that just use WiFi. These often but not always require a cloud service.

On the DIY front people usually use WiFi enabled ESP8266, or a cheap transceiver like an RFM69. For WiFi people usually either implement a REST API on the device or implement MQTT messaging. For the lower level wireless like the RFM69 people build a gateway that translates to IP, again usually REST or MQTT.

But one thing to realize is there is no one technology to rule them all. You will end up with combination of approaches (note I completely ignored wired) which is fine as that is openHAB’s raison d’être.

1 Like
5

That’s what I needed… Thanks…

6

With my limited HA experience, I think MQTT is probably going to be best for me. Not because it’s easier I think it offers more what I need and desire long term.

At the three distribution points (closets) I will have a 16 port fused power distribution box 30A, one 16 channel sainsmart 12v relay and a Pi 3. The PI 3 uses python scripts to turn on or off the relays via it’s GPIO pins.

My MQTT Broker and OpenHab servers are running on my Mac Mini.

I think I have everything installed and functioning (still need Mosquito MQTT on PI 3). now trying to figure out how to start setting it all up. I am guessing at this point I need to start building sitemaps in openhab designer. Still need to test MQTT send/receive too, after I get MQTT on PI.

Am I assuming right that I will be able to send pushes to the PI3 via MQTT and have the PI execute python scripts? Also receive status updates from the PI to the MQTT broker then to OpenHab (I am guessing this is the correct flow).?.?

Thanks…

7

You should look at this script I wrote:

It is a Python server running written to run on a Pi to send messages and receive commands over MQTT with OH.

You only need one MQTT broker. Do not install Mosquitto on the Pis.

The way I would move forward is:

  • Use sensorReporter or write your own MQTT client to run on the Pi. Test to make sure you can send and receive messages in this script. mosquitto_sub and mosquitto_pub (or whatever is the equivalent for the broker running on your Mac)
  • Set up OH to connect to the MQTT broker and start creating Items to represent these devices, test.
  • Start creating the Sitemap to make testing easier and start designing your interface
  • Start writing Rules to control everything automatically
  • Bring in persistence to make OH more robust and enable the ability to use historic data to drive your automation

This will be an iterative process. Start with one or two things and iterate through the steps. Then add more and repeat forever. You will probably never really be done as you will come up with more things to automate.

MQTT doesn’t work like that. One client publishes a message to the broker and other clients subscribe to those messages. The pub/sub point is the topic.

Your client (python scripts) already need to be running to receive the messages it subscribes to and when it receives a message it needs to determine what the message does and perform the correct action. For the most part I usually just use the fact that there was a message at all as what I need to trigger the action, ignoring the actual message contents.

Your running client can either kick off external scripts or implement the code natively. NOTE: sensorReporter has an rpiGPIOActuator class that will toggle or set a GPIO pin to high or low when it receives a message on a specified topic as well as a rpiGPIOSensor that reports the UP/DOWN state of a pin to a specified topic. I use these to trigger my garage door openers (controlled through relays attached to GPIO pins) and report whether or not the door is open based on some reed switches (wired to GPIO pins).

8

Thanks for all the info and sorry for the long delay in replying.

I’ve been busy and here is basically what I’ve gotten done.

I have two RPi 3s with my sainsmart 16 relay boards and logic leveler, etc… done.

I have MQTT setup on both broker on one along with OH. The client one of course doesn’t have the broker or OH installed. I can pass MQTT message between them.

I’ve installed your scripts and starting to look into them more but damn that is a little over my head at the moment.

I assume in the default.ini I will use the [Actuator] sections for my GPIOs? ??

If so, in that section it calls “Pin:” am I to assume that is using the board numbering scheme or BCM on the Pi?

On the “command:” like can I execute a python script? If so, what permissions requirements are there?

Sorry for the million stupid questions but I am a fast learner, at least I hope so at 50 now. LOL

Oh and is there a log to monitor in real-time?

9

For those that you want to control you use actuator. For those you want to report (e.g. sensors) you use sensor.

I thought I had put that in the comments in the .ini but I put it in the code. It is BCM numbering. I’ll update the default.ini comments accordingly when I get a chance.

You can though if it is a python script I’d look into making it run inside the currently running script by adding a new module that calls it.

Anyway, the Python script needs to have execute permissions for what ever user sensorRerporter is running under. If you chmod a+x on the script any user can execute it. Also, if the first line of the Python script is not #!/usr/bin/python you need to use the command python <name of script> <arguments to script>.

If you have syslog enabled in the Logging section of the .ini file:

tail -f /var/log/syslog | grep sensorReporter

If not:

tail -f <path to log file>

Where <path to log file> is what ever is supplied for File: in the Logging section.

No problem with the questions. I hope you get it all working.

10

Sorry I made more progress last night after typing this.

BCM I did find the setting in the default.ini it was documented sorry.

Ok, so I was able to get sensorReporter to read the brokers MQTT pub from another box published to that actuators topic and turned the light on/off. Your default ini has it turn on and off the GPIO quickly.

I assume you set this on/off quickly to test. I’m trying now to figure out how to make it stay on when signal sent and off when it receives another. I thought that was how you had it set. :slight_smile: Now gotta dig deeper on how GPIO settings work. lol.

If I do stop the script and restart I am getting the GPIO channel already in use error msg. I assume this is ok and should set the warnings flag to False?

BTW, I did wind up putting the OH server on the same RPi3 as the broker and not putting it on my Mac Mini.

Oh yeah and you mentioned wired. I would prefer anything that could be wired to be done so. I’m searching now at security camera setup to use and I want it all wired. It’s too easy to jam wireless (cut myself off at the knees a few times with my drones jamming my wifi). So any suggestions on devices and settings for wired connections would be great too. I will use wifi but would prefer wired when I can. Like I stated in the first post I use quite often 433MHz (HAM Freq), 2.4GHz, 5.8GHz & 900MHz frequencies. Some of those with 2 Watt Tx power. My 900MHz drone telemetry signal can reach 40+ miles line of site. :slight_smile:

RTFM “NEVER” !! LOL

11

I toggle it fast like that because I wrote the script to simulate a button press on my garage door opener. If you change Toggle: to False it will permanently change the state of the pin until it receives another message which would be more appropriate for controlling something like a light.

It would be trivial to add support to where you can tell it what to do in the MQTT message itself. Right now it treats the fact if a message to command it regardless what the message is.

I get this too. It doesn’t seem to cause any problems so I haven’t looked into its cause yet.

Unfortunately I have no experience with wired technologies myself so won’t be much help choosing the best. Most of the users on this forum are in Europe where KNX is pretty popular. Beyond X10, I don’t know US wired technologies in theory and personally primarily use wireless.

12

I had already tried “False” and blank and multiple other things none worked it still did on/off rapidly.

Here is ini

[Actuator1]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actuators can call
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 2
Topic: kit/barlight
; When true set the pin to ON for half a second then turn off, otherwise switch the pin from one state to the o$
Toggle: False
Poll: 0

[Logging]
File: /var/log/mqttReporter.log
MaxSize: 67108864
NumFiles: 10
Syslog: NO

[Connection1]
Class: mqttConn.mqttConnection
Name: MQTT
User = *****
Password = ***********
Host = ***.***.***.****
Port = 1883
Keepalive = 60
; Topic to listen on, when any message is received, the current state of all
; are published to their respective topics.
Topic = sensors/getUpdate
; The MQTT broker will publish the following message on the following topic
; when the client disconnects (cleanly or crashes)
LWT-Topic = status/sensor-reporters
LWT-Msg = mqttReporter is dead
; If TLS is yes the connection will be encrypted, the Certificate is expected to be in
; ./certs/ca.crt"
TLS = NO

[Connection2]
Class: restConn.restConnection
Name: REST
URL = http://localhost:8080/rest/items/
13

It might be broken. I’ll take a look at the code this evening. I only ever use the toggle so this functionality really hasn’t been tested, at last by me. Though I think I accepted a PR on this functionality so I need to look into it.

14

I tinkered for a few hours last night and could not get it yet. :frowning:

15

I looked at the code. As written it should, if the message sent to the script is ON it will set the pin to LOW, otherwise it will send the pin to HIGH

The relevant lines are the last two in rpiGPIOActuator.py

16

If I pub from another session on the broker SS picks it up on the client and executes the script. I can modify the delay etc but setting it to False does not skip to the else: in rpiGPIOActuator.py from what I can see. everything thing else checks out.

Here is the output from mqttreporter when I send a publish

2016-11-26 21:58:31,560 INFO - Toggling pin 2 HIGH to LOW
2016-11-26 21:58:35,565 INFO - Toggling pin 2 LOW to HIGH

Here is my ini

[Actuator1]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actuators can call
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 2
Topic: kit/barlight
; When true set the pin to ON for half a second then turn off, otherwise switch the pin from one state to the oth$
Toggle: False
Poll: 0

[Actuator2]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actuators can call
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 3
Topic: kit/counterlight
; When true set the pin to ON for half a second then turn off, otherwise switch the pin from one state to the oth$
Toggle: False
Poll: 0

[Logging]
File: /var/log/mqttReporter.log
MaxSize: 67108864
NumFiles: 10
Syslog: NO

[Connection1]
Class: mqttConn.mqttConnection
Name: MQTT
User = user
Password = password
Host = 192.168.0.60
Port = 1883
Keepalive = 60
; Topic to listen on, when any message is received, the current state of all
; are published to their respective topics.
Topic = sensors/getUpdate
; The MQTT broker will publish the following message on the following topic
; when the client disconnects (cleanly or crashes)
LWT-Topic = status/sensor-reporters
LWT-Msg = mqttReporter is dead
; If TLS is yes the connection will be encrypted, the Certificate is expected to be in
; ./certs/ca.crt"
TLS = NO

The MQTT topic log:

Client mosqsub/2081-raspberryp received PUBLISH (d0, q0, r0, m0, 'kit/barlight', ... (2 bytes))
On

And the rpiGPIOActuator.py

import sys
import time
import RPi.GPIO as GPIO

class rpiGPIOActuator:
    """Represents an actuator connected to a GPIO pin"""

    def __init__(self, connection, logger, params):
        """Sets the output and changes its state when it receives a command"""

        self.logger = logger

        self.pin = int(params("Pin"))

        GPIO.setmode(GPIO.BCM) # uses BCM numbering, not Board numbering
        GPIO.setup(self.pin, GPIO.OUT)
        GPIO.output(self.pin, GPIO.HIGH)

        self.destination = params("Topic")
        self.connection = connection
        self.toggle = bool(params("Toggle"))

        self.logger.info('----------Configuring rpiGPIOActuator: pin {0} on destination {1} with toggle {2}'.form$
        self.connection.register(self.destination, self.on_message)

    def on_message(self, client, userdata, msg):
        """Process a message"""
        self.logger.info('Received command on {0}: {1} Toggle = {2} PIN = {3}'.format(self.destination, msg.paylo$
        if self.toggle == True:
            self.logger.info('Toggling pin %s HIGH to LOW' % (self.pin))
            GPIO.output(self.pin, GPIO.LOW)
            time.sleep(4)
            GPIO.output(self.pin, GPIO.HIGH)
            self.logger.info('Toggling pin %s LOW to HIGH' % (self.pin))
        else:
            out = GPIO.LOW if msg.payload == "ON" else GPIO.HIGH
            GPIO.output(self.pin, out)
17

For grins, what happens if you change

if self.toggle == True

to

if self.toggle == "True"
18

Yup That was it…

19

Thanks! I’ll add an issue and have it fixed in the mainline version soon.

20

UPDATED: After blowing away the play RPi I installed from scratch to get a clean install going. At first I did not install the client as it was only the broker so I thought it did not need the mosquito-client too but it appears it does. I did not use the paho install but did use the apt-get method below. It’s working now but not sure if I’m going to run into something down the road since I did not do the paho install.

apt-get install mosquito mosquito-clients (think the syntax is right)

instead of using

pip install paho-mosquitto (syntax might not be right again but you know).

Everything is working so far is there a reason to do the paho version of the client? I also thought the broker software did away with the server needing the client side installed and that was only for the clients. My assumption there seems to be incorrect.