I have a simple (default) mqtt set-up that works…
Nothing but default settings in OH and mosquitto; no password, etc.
Exception from default: I do have a second listener defined on port 8883; though TLS)
OH and mqtt is working; e.g.
2017-01-17 16:23:58 - Network_Router_LAN state updated to ON
2017-01-17 16:23:58 - Network_ATA state updated to ON
2017-01-17 16:24:00 - Hub_BorePump_Demand state updated to ON
2017-01-17 16:24:00 - Bore_Pump_Status state updated to ON
2017-01-17 16:24:01 - mobMaxG state updated to present
2017-01-17 16:24:14 - Weather_Humidity state updated to 45
2017-01-17 16:24:14 - Weather_Temperature state updated to 32
2017-01-17 16:24:14 - Weather_LastUpdate state updated to 2017-01-17T16:24:14
2017-01-17 16:24:15 - Hub_BorePump_Demand state updated to ON
2017-01-17 16:24:15 - Bore_Pump_Status state updated to ON
2017-01-17 16:24:16 - Tank_Irrigation_Demand state updated to ON
2017-01-17 16:24:17 - Tank_Irrigation_Level state updated to 2
E.g. Tank, Bore, Hub are all MQTT message based.
The iPhone at present connects via local WiFi.
However, I publish the originally received messages for enter and leave to test mqttitude in OH.
Subscribing to the same topic (via terminal) will show the very same message.
Yes, I am not sure why I have owntracks/owntracks in the topic; as the examples I see do not.
But this does not matter ATM, nor does not seem to be the problem.
As you said: it seems to register / subscribe to this msg.
Yep so checking the source code (which I wrote many years ago ;)) there is definitely trace logging configured to help debug these sorts of issues. Any message received by the binding subscription is logged via;
logger.trace("Message received on topic {}: {}", topic, decoded);
The fact you are not seeing these either means your logging is not configured correctly, or for some reason the messages are not getting thru to the binding. The fact the Registering Mqttitude consumer for xxx is being logged seems to mean your item config is correct.
I would focus on the logging side of things I think.
That logging config looks fine. I just checked again and the only place that there is trace logging is inside the MQTT consumer, meaning if you don’t receive any messages you won’t see anything extra in the logging.
So it perhaps means that for some reason openHAB isn’t receiving those pubs to that topic.
Can you do a mosquitto_sub using the same user/pwd as openHAB uses and then do your test pub to that topic and make sure it is appearing?
2017-01-17 19:33:11 - mqttitudeTest state updated to {"desc":"Home","t":"c","tst":1484616290,"acc":50,"lon":152.3871252314675,"_type":"transition","wtst":1484570767,"lat":-27.32542779299181,"event":"leave","tid":"MG"}
so OH can subscribe / work this particular publish command.
Also, re-installed the binding with apt-get, same log msgs and behaviour. My initial install was simply dropping the binding into ‘addons’.
When I add a debug item that subscribes to messages on the same topic I get messages so that would, in my case, rule out a configuration error in mqtt.conf.
I haven’t moved the phone out of the geofence or spoofed any MQTT-messages so I in order to confirm that the MQTT configuration works I subscribed directly to the device topic and not to the /event topic.
13:32:02.523 [INFO ] [marthome.event.ItemStateChangedEvent] - mqttitudeTest changed from {"_type":"location","tid":"ik","acc":9,"batt":67,"conn":"w","doze":false,"lat":XX.XXXXXXX,"lon":YY.YYYYYYY,"tst":1484655994} to {"_type":"location","tid":"ik","acc":30,"batt":67,"conn":"w","doze":false,lat":XX.XXXXXXX,"lon":YY.YYYYYYY,"tst":1484656321}
I personally am running 1.8.3. Sounds like Fredrik has got his issue sorted. Since you have proven that your MQTT broker is receiving those messages I think the only thing left is your item config (but I am not sure what).
Can you post your full items config currently? I would suggest paring it right back to a single Switch item to remove any confusion and see if we can make any progress with that.
no entry related to mqttitude in openhab.conf
mosquitto (has been and) is running nicely
mqttitude does not seem to process the messages.
After reducing the items config to one switch, I rebooted the rPi (just to be sure)
On a side note: if you have 1.8.3 running, why not check the log level by adding TRACE to the logger, and see, what the outcome of openhab.log is. Even if I set it to TRACE it says DEBUG in the log. (The same with the EXEC and Yahoo weather binding); so I doubt that the openhab.log will show TRACE as a word; whether this affects its inner working; e.g. whether it does actually do TRACE I cannot tell.
In any case, thank you for your continued help with this issue.
@westermarck: As you can see in a previous post, I have done exactly the same. In my case (as I suspect in yours) mosquitto is working. But the mqttitude binding, despite subscribing to the OwnTracks topic does not seem to process any of it.
Be aware you are on OH 2 and I am on OH1 = different binding versions.
I did the mosquitto item and it works…
… and have no entries related to mqttitude in the openhab.conf
But why not; will try the empty entries
@ben_jones12: don’t stress about it; I feel you’ve done the best you could…
sometimes there things beyond what we see…
OK, added the mqttitude section in openhab.conf with uncommented parameters and leaving them ‘empty’… result:
after restart with mqttitude empty values
2017-01-18 10:32:47.913 [INFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2017-01-18 10:32:47.918 [INFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'mymosquitto'
2017-01-18 10:33:07.715 [DEBUG] [.m.internal.MqttitudeActivator] - Mqttitude binding has been started.
2017-01-18 10:33:07.777 [DEBUG] [.b.m.internal.MqttitudeBinding] - Registering Mqttitude consumer for owntracks/owntracks/maxg-iphone/event (on mosquitto)
2017-01-18 10:33:07.780 [DEBUG] [.b.m.internal.MqttitudeBinding] - Activating Mqttitude binding
2017-01-18 10:33:07.785 [DEBUG] [.b.m.internal.MqttitudeBinding] - Mqttitude binding configuration updated, no 'home' location specified. All item bindings must be configured with a <region>.
2017-01-18 10:33:07.792 [DEBUG] [.b.m.internal.MqttitudeBinding] - Unregistering Mqttitude consumer for owntracks/owntracks/maxg-iphone/event (on mosquitto)
2017-01-18 10:33:07.802 [DEBUG] [.b.m.internal.MqttitudeBinding] - Registering Mqttitude consumer for owntracks/owntracks/maxg-iphone/event (on mosquitto)
2017-01-18 10:33:08.974 [WARN ] [o.p.m.i.MqttPersistenceService] - mqtt-persistence:broker
2017-01-18 10:33:08.975 [WARN ] [o.p.m.i.MqttPersistenceService] - mqtt-persistence:topic
2017-01-18 10:33:08.977 [WARN ] [o.p.m.i.MqttPersistenceService] - mqtt-persistence:message
msoquitto log:
1484699546: Socket error on client openhab, disconnecting.
1484699568: New connection from 127.0.0.1 on port 1883.
1484699568: New client connected from 127.0.0.1 as openhab (c1, k60).
1484699760: New connection from ::1 on port 1883.
1484699760: New client connected from ::1 as mosqpub/14933-rpiautoma (c1, k60).
1484699760: Client mosqpub/14933-rpiautoma disconnected.
1484699793: New connection from ::1 on port 1883.
… in essence no change, and no TRACE messages or further DEBUG messages when publishing the owntracks messages…
I do not understand the inner workings of OH or mqtt… but the mosquitto.log shows and entry at epoch 1484699760 (18 January 2017 10:36:00 GMT+10:00) connecting and disconnecting a mosqoub on rpiAutomation… could this a problem.
I did not define this name; so it must be auto assigned??
Is this relevant?
