We have decided to Spin up a new vm with the apt-get installation of open hab to see if that helps us with any issues we are having. Ill let you know as soon as we are ready to start testing again on the new installation.
Hi there Rich, I have been trying to help Steven (computeq) with setting up his openHAB environment but we are both beginners here and are running into some issues (in case the earlier posts didnât tip you off lol). We reinstalled openHAB as you suggested using the apt-get method which went very smoothly but we are having issues getting openHAB to respond to published MQTT messages and I canât figure out why. I think we might not be formatting the published message correctly but Iâm not sure. Below is an example of one of the item switches we are trying to update with our published MQTT message as well as the transform mapping.
Switch Door_G_Bayright âRight Doorâ (Doors, gG) {mqtt="<[home:openhab/garage/door2/state:state:MAP(onoff.map)]"}
mosquitto_pub -h 10.5.5.100 -p 8883 -t âopenhab/garage/door2/stateâ -m â1â
GNU nano 2.2.6 File: onoff.map
0=OFF
1=ON
-=unknown
off=OFF
on=ON
We can see the published message appear on the MQTT broker but for some reason openHAB doesnât do anything with the message sent and we havenât been able to find any errors openHAB or any indication that openHAB is seeing the message. We have configured the MQTT binding and am fairly sure it is set correctly as the openHAB log shows it is connecting to the broker at startup.
Any further guidance you or anyone else can provide is greatly appreciated!
Thanks,
Luis
When I hit problems like this reduce complexity and work backwards towards the source of the message.
-
prove the message is sent using something else like mosquitto_sub, which it sounds like you have done
-
Change Item to a String type and use default for the transform. This eliminates any possibility that the transform is having trouble parsing the message. Often leading or trailing spaces or \n\r characters will cause trouble
-
Check events.log to make sure that your Item is getting updated when you send the message.
If you are getting the raw message the trouble isnât in MQTT but in the transform. If you have the power to do so, change the sender to use ON and OFF as the messages. These will naturally parse into a Switchâs state without the need for a transform. If not, print the String Itemâs state with quotes around it in the hopes we can see if there is some errant white space in there. The map file will need to include that white space or you will need to use something like a JS transform to trim off the whitespace and move it to all caps or convert 0 to OFF and 1 to ON.
NOTE: The MQTT binding is expecting Strings, not ints or floats or binary blobs. Make sure your devices are sending â1â not 1.
Double and triple check the topic is identical.
It is frustrating not being there to see what you are seeing so I can only really tell you what I would do to figure it out.
Hello,
I thought i would be the first to let you know we got it working!!! It looks like there were some files that got mixed up durring our original âmanualâ installation and we decided to spin up a new VM for open hab and start from scratch. We now have mqtt talking with open hab and visa versa with the site map updating as required⊠Now im on the raspberry pi and your scripts that you wrote. We will keep you posted as we make progress but im excited to have a small amount of things working soon! Garage Doors Open Sesame ! 
lol ⊠Thanks again for all your help with this we appreciate all you do for the openhab community and us.
Woohoo! Glad it is working!
Hey Rich,
So on to the next snag⊠The Pi and sensorReporter. So ive been messing around with this for a few days following your install process but i seem to be stuck on a couple of different things. The first is that the Service wont start and here is the service Status log.
Dec 12 01:39:22 Furnacepi sensorReporter.py[1351]: File â/opt/sensorReporter/sensorReporter.pyâ, line 178, in loadConfig
Dec 12 01:39:22 Furnacepi sensorReporter.py[1351]: configLogger(config.get(âLoggingâ, âFileâ),
Dec 12 01:39:22 Furnacepi sensorReporter.py[1351]: File â/usr/lib/python2.7/ConfigParser.pyâ, line 607, in get
Dec 12 01:39:22 Furnacepi sensorReporter.py[1351]: raise NoSectionError(section)
Dec 12 01:39:22 Furnacepi sensorReporter.py[1351]: ConfigParser.NoSectionError: No section: 'Loggingâ
Dec 12 01:39:22 Furnacepi systemd[1]: sensorReporter.service: main process exited, code=exited, status=1/FAILURE
To me it looks like its complaining that it does not see the âloggingâ section in the config file⊠However i can assure you it is there here is a copy of the Furnacepi.ini
[Sensor1]
; Native Raspberry Pi Library
Class: rpiGPIOSensor.rpiGPIOSensor
Pin: 7
Connection: MQTT
Destination: sensor2/topic
PUD: DOWN
Poll: 0.5
[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: 17
Topic: actuators/actuator1
; When true set the pin to ON for half a second then turn off, otherwise switch$
Toggle: True
Poll: 0
[Logging]
File: /var/log/mqttReporter.log
MaxSize: 67108864
NumFiles: 10
[Connection1]
Class: mqttConn.mqttConnection
Name: MQTT
User = user
Password = password
Host = 10.5.5.100
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 next question i have is about the actuator. I see that you have two options laid out in the config file to either âtoggleâ or alternate the pins state low to high high to low. My question is what is it that the script is looking for inside the topic to actually start the actuator? Looking through the code it seems to be 1 or 2. 1 being to activate the pin and alternate the pins state or 2 which would be to toggle running the wait timer before cycling from low to high? ⊠Or am i reading way to much into this and its acctually the msg.payload ON ???
I tend to over think things some times but i wanted to ask the man who wrote this out 
Thanks so much as usual
Thanks,
SteveT
So after a little more huting i discovered that the symbolic link was not working so it was unable to load the config file⊠however this is the error i get nowâŠ
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: File â/opt/sensorReporter/sensorReporter.pyâ, line 199, in
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: main()
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: File â/opt/sensorReporter/sensorReporter.pyâ, line 71, in main
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: loadConfig(sys.argv[1])
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: File â/opt/sensorReporter/sensorReporter.pyâ, line 181, in loadConfig
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: config.get(âLoggingâ, âSyslogâ))
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: File â/usr/lib/python2.7/ConfigParser.pyâ, line 618, in get
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: raise NoOptionError(option, section)
Dec 12 03:49:30 Furnacepi sensorReporter.py[1547]: ConfigParser.NoOptionError: No option âsyslogâ in section: 'Loggingâ
Dec 12 03:49:30 Furnacepi systemd[1]: sensorReporter.service: main process exited, code=exited, status=1/FAILURE
System logging is turned on not sure if im supposed to specifiy that or what.
The start configs sensorReporter.service assumes you have a sensorReporter.ini file which contains your configurations.
If you did not, do one of the following:
-
change this file to use Furnaceapi.ini then sensorReporter is loading with NO configuration.
-
change the name of Furnaceapi.ini to sensorReporter.ini
-
create a synmbolic link between Furnaceapi.ini to sensorReporter.ini
Note, this assumes the .ini is in the same folder as sensorReporter.
I should add some checking to see if the file exists before blindly running and failing on the first section it attempts to parse (i.e. Logging).
Iâve made a comment in the code. But I neglected to make the same comment in the default.ini.
It will set the pin to GPIO.LOW if the message is ON. It sets it to GPIO.HIGH for all other messages.
Iâll add this comment to default.ini and the readme.
the line of code of interest is the very last one in the file:
out = GPIO.LOW if msg.payload == "ON" else GPIO.HIGH
Note, I recently pushed a fix that was preventing the code from running that part of the code no matter what you put into the .ini file. Make sure you have the latest.
How long ago did you download? There was a bug I fixed a little while back that was causing this error when you didnât supply the Syslog parameter under logging. The new version no longer cares and just assumes NO when it doesnât exist.
Apparently the system link had not worked and this is why it could not read my config file. i fixed that issue but still get the error you responded to about syslog.
I literately built this pi last night so this should be your newest source code if i just cloned it from the git to the pi right?
As to the Out=GPIO.LOW ⊠the transistors on the relay boards i bought accidentally are reversed so they require an absence of voltage to saturate and turn on the relay so in essence i have to send a LOW to the pin to turn them on instead of a high. So what would i send if i want it to toggle ? and is that going to toggle from low to high or high to low?
what is the syntax to add the syslog param to the ini file just to try it ?
Try adding
Syslog: NO
to the Logging section. I thought I had fixed this but as Iâm looking at all my .ini file Iâm seeing that I am always defining it.
That is how mine work too. I think that is normal actually. Anyway, if you review the code, and the line of code I pasted in above, you will see that when you send ON the pin is set to GPIO.LOW. Any other message set it to GPIO.HIGH.
If you set Toggle to True (I really should make these consistent) the code will do the following upon receipt of ANY message:
- set the pin to GPIO.LOW
- sleep for half a second
- set the pin to GPIO.HIGH
There are two types of transistors when making these circuits⊠i just could not remember the names of them one is NPN and the other is PNP 1 requires a positive voltage to saturate the transistor and close the switch the other requires a loss of voltage to close the switch. then of course there are photo transistors that are controlled by light ⊠here i go rambling.
However⊠This fixed the logging error but now i get the followingâŠ
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: File â/opt/sensorReporter/mqttConn.pyâ, line 48, in init
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: self.client.connect(params(âHostâ), port=int(params(âPortâ)), keepalive=float(params(âKeepaliveâ)))
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: File â/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.pyâ, line 686, in connect
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: return self.reconnect()
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: File â/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.pyâ, line 808, in reconnect
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: File â/usr/lib/python2.7/socket.pyâ, line 571, in create_connection
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: raise err
Dec 12 22:36:59 Furnacepi sensorReporter.py[422]: socket.error: [Errno 101] Network is unreachable
Dec 12 22:36:59 Furnacepi systemd[1]: sensorReporter.service: main process exited, code=exited, status=1/FAILURE
this makes me think it cant reach my broker but its alive and on the right port according to the config file. I can also post to it from another pi just fine any ideas ? I can ping this host just fine as well from this pi. and the broker listens on that port from elsewhere. is there a fw turned on in rasbian by default ?
here is the connection1
[Connection1]
Class: mqttConn.mqttConnection
Name: MQTT
User = user
Password = password
Host = 10.5.5.100
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
One last little tid bit of info as well this is what the logs show
2016-12-12 22:36:59,232 INFO - ---------------Started
2016-12-12 22:36:59,233 INFO - Creating connetionsâŠ
2016-12-12 22:36:59,234 INFO - Creating connection MQTT
2016-12-12 22:36:59,681 INFO - Configuring MQTT connection to broker 10.5.5.100:1883
Iâve seen this error when mosquitto refuses the connection as well. Or when using TLS and the certs donât match up. Look in mosquittoâs logs when it tries to connect and see if it happens to indicate whether it is getting the connection request and, if we are lucky, why it is refusing it. Iâve also read of others having trouble when they use the same Name: for multiple clients so make sure the Name field is unique across all of your clients.
Try installing mosquitto-clients on the pi and see if you can pub and sub using those same settings using it. It now maybe it will provide more useful messages than the Paho library seems to be doing.
sudo apt-get install mosquitto-clients
When you say clients name where was that specified ?
I figured it out⊠a rather ambiguous error lol ⊠this connection has no creds right now but i left your default script ones in there hahahaha Thanks!
Glad you figured it out. The first thing I ever did with MQTT was set up authentication so Iâve never tested without needing to provide user and password.
I was trying to simplify things as we ran into problems early on with MQTT so we left it open for now but will be securing it before everything goes into production.
Last question and then ill leave you alone for the nightâŠ
On the sensors what is it going to be published to the topic if the sensor is activated by way of completing the connection on the GPIO pins? is that the PUD?
I set it up to work as easily as possible with openHAB (i.e. no transforms required). So when the pin is GPIO.LOW the message published is CLOSED and when the pin is GPIO.HIGH the message published is 'OPEN`. If you use Contact Items you need do nothing special to the message for OH to convert that string to a proper State.
Alright thanks again⊠i swear last question lol I see now that the mqtt logs are showing the pin as being toggled but ⊠i dont see anything happening on the GPIO pin that ive specified⊠this is on a raspberry pi 3 do i need to add more sleep time ? any thoughts?
To add to this ON is working and i can turn the pin on and then send any command to turn it off but the toggle function is what is not working
Iâm not really sure. Half a second is pretty fast. It might be possible that it isnât enough to see the change on what ever it is you are controlling. My relays have a red light and make a clicking noise when they change state which I used when first testing my setup out.
You can change the sleep by editing the code. The last function in the file is where the magic happens. The fact that it works when you just set it to ON or OFF shows that the code can control the pins.
Is the function Time installed by default on the newest version of Rasbian with this version of python ? i was wondering if the timer just isnt running so it never gets to the next piece of code⊠just for clarification the config param is Toggle: = True ?? just to make sure its not skipping over that part of the config⊠im shooting in the dark because i really need the toggle function to work for the garage doors as those are momentary switches.