I’m not 100% certain I follow exactly what you did. In general you don’t need the mosquitto-clients unless you want to run the mosquitto-sub and mosquitto-pub commands for testing. You shouldn’t have to install mosquitto-clients at all, though it has been long enough since I’ve done it that I could be wrong.
The openHAB MQTT binding comes with paho so you don’t need to install paho separately for openHAB.
sensorReporter does require the paho python library be installed manually as a separate step. That is one of the steps in the install.sh script which is more of a documentation of what you need to do to get sensorReporter to run and less a true installation script.
Sorry, reading it again I don’t even understand it. That was a bad day so I took a few off to clear my head and start again.
Ok here is what I have now. MQTT broker is passing messages to the clients. I can turn on and off the relays passing ON/OFF via _pub to the respective topics.
I installed OH and can connect to it with a simple sitemap. I tail the OH events log and I see this when flipping the switch using the OH GUI but do not see it published to the topic.
2016-12-01 20:18:35 - mqttsw1 received command ON
2016-12-01 20:18:35 - mqttsw1 received command OFF
But the message isn’t making it to the MQTT topic. I’m afraid I may have missed a dependency along the way.
Here is my openhab.cfg MQTT Transport section
################################# MQTT Transport ######################################
#
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with a id you choose.
#
# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
mqtt:<broker>.url=tcp://192.168.1.1:1883
# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a default one is generated.
#mqtt:<broker>.clientId=<clientId>
# Optional. User id to authenticate with the broker.
# mqtt:<broker>.user=<user>
# Optional. Password to authenticate with the broker.
#mqtt:<broker>.pwd=<password>
# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.
#mqtt:<broker>.qos=<qos>
# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#mqtt:<broker>.retain=<retain>
# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
#mqtt:<broker>.async=<async>
# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>
#mqtt:<broker>.lwt=<last will definition>
Actuator1]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actua$
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 2
Topic: lights/kit/bar
; When true set the pin to ON for half a second then turn off, otherwise switch$
Toggle: False
Poll: 0
[Actuator2]
Class: rpiGPIOActuator.rpiGPIOActuator
; The chosen connection must support a register(path, handler) method the actua$
; to receive specific incoming messages. See mqttConn.py for an example
; restConnection is not supported.
Connection: MQTT
Pin: 3
Topic: lights/kit/counter
; When true set the pin to ON for half a second then turn off, otherwise switch$
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.1.1
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 t$
; ./certs/ca.crt"
TLS = NO
Given that the rest of the parameters are commented out I’m assuming that you have not configured Moqsuitto to require a username and password. However, you do have a user and password defined in sensorReporter. Since sensorReporter seems to be working, make sure mqtt:mosquitto:user and mqtt:mosquitto:pwd match those used in sensorReporter.
Ok… Still not turning on and I did replace all the “broker” with mosquitto, duh should have seen that. Not sure if I saw this before or not but in the sensorReporter window when I now turn on via OH I see this.
I also matched the openhab.cfg usr/pwd to match what I have in sensorReporter.ini. I did NOT however set it on the broker on pub.
Do you get any errors in the log? When you run systemctl status sensorReporter after a reboot do you see any errors?
I’ve intermittently had it not start when my Pi reboots too but I’m seeing all sorts of other weirdness on that Pi (probably a failing SD card) and attributed it to that. But if you are seeing the same problem then it might be a bigger issue.
Not sure if you have checked in to it. But there is a system called mysensors.org. Uses a gateway to talk to RF devices you build. The gateway just communicates with mqtt. I use openhab as well and love my mysensors.org add on. I have been building whatever various modules, and in the end openhab or whatever other controller you want just has to talk to MQTT.
Ok, now that relays are working time to move onto something else. I have a couple of envirophats https://github.com/pimoroni/enviro-phat laying around and hooked one up to a Pi zero and got her working.
Now, I need to create a class for it and believe me I butchered my first attempt. LOL… Too embarrassed to even post it, yup it was that bad.
Please point me in the right direction, yeah from the beginning, and I’ll muddle my way around.
Hmmm, that is the same error I’m seeing. There must be something else going on. I wonder if there is boot time dependency that I’m missing. I’ll look into it some more now that I know it isn’t just me.
Your best bet is to look at the rpiGPIOSensor.py as an example for how to integrate it with sensorReporter.
I set everything up so all you have to do is put your new class files in the same folder and fill out a section in the .ini file and you are good to go. It figures out what class to create based on the Class parameter and it passes the rest of the parameters to the class in the constructor.
There are two different types of sensors, those that sensorReporter controls the polling for (e.g. rpiGPIOSensor.py) and those that the class does its own polling or is set up to receive events (e.g. dash.py). If it is a polling class then periodically sensorReporter will call “checkState” and “checkState” should publish a new state if it has changed, or how ever you want to do it (e.g. publish state changes and publish the current state every five minutes).
When sensorReporter receives a message on its topic it will call publishState on each class to send out the current state.
For non-polling classes, the creation of and control of the polling is implemented in checkState and publishState does nothing.
You shouldn’t need to touch any of the other classes to make it work.
I don’t know how the envirophat libraries work so I can’t say for sure which type you need.
But I think you will find it isn’t too hard. You might just create a quick and dirty python script of your own to figure out how the envirophat libraries work then migrate that to a sensorReporter sensor.
It looks like the Envirophat library has a compatible license to sensorReporter so once you get this working I’d welcome adding it to the main sensorReporter repo. Or I’d encourage you to publish your own.
I am pretty certain that mysensors is not a hosted platform. At least not based on those I’ve helped around here getting it to work. I will say though that it is not the easiest to get working if you are not technically adept and willing to learn.
Stopping on the envirophat idea for awhile since it’s temp sensor is 10+ degrees off from calibrated one. I think there are some issues with it if precision is your game.
Right now I’m trying to get Siri to work to the MQTT broker. I installed homebridge and can connect to it via HomeKit app. Now gotta figure out how to get the devices in to send the right MQTT msg to the broker. Any pointers?
I’ve been very happy with the accuracy of the DHT22s I have wired to some arduinos. I haven’t done any true calibration of them but I’ve some other commercial thermometers around and the temp and humidity match when they are placed in the same location.
Our house is a mixed house so I purposely avoid those technologies/APIs that are limited to one ecosystem. In short, I know squat about Siri or HomeKit.
I’ve had exactly 0 time to look into it and probably won’t until after the new year. I have on my todo implementing a plug-in that would work with systemd’s watchdog service. That would address the problem indirectly.
For the time being I just make sure to check that it came back up in those rare cases where I have to reboot the pis.
Are you using the FDQN? This is indeed odd behavior. I have DNS on my router and I connect to the broker using the DNS name instead of the IP address for all of my configs.
That was a bad day so I took a few off to clear my head and start again.