Vera - Smarter Home Control Forum

Advanced => Programming => Plugins & Plugin Development => Topic started by: SchattenMann on January 19, 2016, 08:34:47 am

Title: MQTT Client Plugin
Post by: SchattenMann on January 19, 2016, 08:34:47 am
MQTT Client Plugin

This plugin provides the ability to publish out any user defined variable to an MQTT Broker.
It is based on the code found here (http://forum.micasaverde.com/index.php/topic,17432.15.html)
This is my first plugin so odds are there will be some bugs although so far seems to be working fine.

This plugin is designed for use on systems running UI7.

Features


MQTT Message Example

Code: [Select]
{"Payload":{"DeviceId":45,"OldOnOff":"1","OnOff":"0","Time":1453209965},"Topic":"Vera/Events/TestSocket"}
Installation and Configuration



Dependencies


There are a few dependencies that should be copied to /usr/lib/lua folder

Source code

https://github.com/jonferreira/vera-mqtt
Title: Re: MQTT Client Plugin
Post by: 4integration on January 19, 2016, 10:09:35 am
Really nice, great!

Would be even nicer if some screenshots were added :)
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 19, 2016, 10:19:25 am
Thank you.

I shall try it out later :)
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 19, 2016, 11:52:55 am
I am stuck. How do I upload those files to the Vera?
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 19, 2016, 12:39:40 pm
I suppose you're both talking about the dependencies...
These need to be uploaded to /usr/lib/lua folder as explained on the first post.
You can do this via SSH or with WinSCP
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 19, 2016, 12:40:37 pm
Really nice, great!

Would be even nicer if some screenshots were added :)

That's the next step, just run out of time
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 19, 2016, 04:28:30 pm
I suppose you're both talking about the dependencies...
These need to be uploaded to /usr/lib/lua folder as explained on the first post.
You can do this via SSH or with WinSCP
But what is the ssh I'd and password then?
I've only ever logged on via the Web site.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 20, 2016, 04:39:19 am
I suppose you're both talking about the dependencies...
These need to be uploaded to /usr/lib/lua folder as explained on the first post.
You can do this via SSH or with WinSCP
But what is the ssh I'd and password then?
I've only ever logged on via the Web site.

username is root and password is your Vera's Wireless Password
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 20, 2016, 05:13:05 am
UI screenshots attached
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 20, 2016, 08:05:18 am
When I try to WS-FTP in to the Vera using SSH I get the following:

Error 842c0000 receiving sftp packet
error 842c0000 initializing sftp protocol
Sending channel close message for channel 0760a2ce
SSH Transport closed.

I can log in using SSH command line using Putty though.

Is there any documentation on this? I don't want to have to keep pestering you all the time... that isn't fair on you :)
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 20, 2016, 08:14:43 am
When I try to WS-FTP in to the Vera using SSH I get the following:

Error 842c0000 receiving sftp packet
error 842c0000 initializing sftp protocol
Sending channel close message for channel 0760a2ce
SSH Transport closed.

I can log in using SSH command line using Putty though.

Is there any documentation on this? I don't want to have to keep pestering you all the time... that isn't fair on you :)

Not sure if SFTP will work (never tested it myself) but WinSCP  (https://winscp.net/eng/download.php)definitely does.

Beware though you have to disable "Secure my Vera" first under Users & Account Info - Unit Settings
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 20, 2016, 08:59:07 am
Thx. Used WinSCP.

So I have uploaded the dependencies to the correct location and added the plugin files to the Luup files via the dashboard.

Now I am stuck again... how do I create the device? I have tried via the Device Add process and I can see nothing to do with MQTT in the list of possible devices. I have tried to add a device via the develop apps but I don't know what to enter for the various fields.

This is why I asked if there was some documentation on how to add new plugins.

Sorry to pester.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 20, 2016, 09:01:49 am
Thx. Used WinSCP.

So I have uploaded the dependencies to the correct location and added the plugin files to the Luup files via the dashboard.

Now I am stuck again... how do I create the device? I have tried via the Device Add process and I can see nothing to do with MQTT in the list of possible devices. I have tried to add a device via the develop apps but I don't know what to enter for the various fields.

This is why I asked if there was some documentation on how to add new plugins.

Sorry to pester.

Sorry, so used to this that I've forgotten to add that information.
screenshot attached
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 20, 2016, 11:37:08 am
Right... we are getting there.

So I now have the device in my devices list. What now?

How can I send a MQTT message to my MTTT broker with, say, the status of one of my Vera controlled devices?

How can I read a topic from the MQTT broker and then say, activate a device on the Vera?

Can I do these things?

You wouldn't believe I am a very experienced software developer of 30+ years would you... I feel like a total noob.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 20, 2016, 01:27:23 pm
So I now have the device in my devices list. What now?

My apologies, I?d forgotten about the initial configuration (I?m planning to release a quick guide anytime soon but haven?t got the time yet)

On the Advanced ? Variables tab set your MQTT Broker IP (mqttServerIp) and Port (mqttServerPort)

How can I send a MQTT message to my MTTT broker with, say, the status of one of my Vera controlled devices?

Simply subscribe a device variable on the "Watchdog" Tab. Say you want to receive notifications when a Relay Is Turned On/Off - subscribe the urn:upnp-org:serviceId:SwitchPower1 - Status Variable

How can I read a topic from the MQTT broker and then say, activate a device on the Vera?

This Plugin is just for Publishing MQTT messages to a MQTT Broker

Hope this help
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 20, 2016, 05:41:49 pm
How then do I specify the MQTT topic and which device?
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 05:14:16 am
How then do I specify the MQTT topic and which device?

For now Topic is hard-coded (next on the to-do list pile)

It will either be Vera/Events/<DEVICE ID> or Vera/Events/<DEVICE ALIAS>

And you don't need to specify which device you want to monitor, that's just unnecessary work and a PITA if you have 100 devices.
You simply set which variables you want to monitor and all devices with those variables will publish status updates - you may then subscribe only the Topics you actually want to monitor but odds are if you need MQTT you're using something like node-red for all your logic and this is a huge help
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 05:25:17 am
Fantastic!

All working.

Thank you for your efforts :)
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 05:27:11 am
Fantastic!

All working.

Thank you for your efforts :)

glad you like it
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on January 21, 2016, 06:15:32 am
I installed the dependencies and the plugin file and created the device.
The device state is 'connected' and I've selected a couple of parameters to monitor.
However, when subscribing to Vera/# I do not see any messages.
Any idea where I can troubleshoot/see logs for this plugin?
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 06:17:43 am
I had the same issue. You may have the same problem I had...

The messages it sends are not persistent. You have to action something on the Vera while being subscribed to the MQTT topic so you can see it as the message is published.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 06:18:18 am
I installed the dependencies and the plugin file and created the device.
The device state is 'connected' and I've selected a couple of parameters to monitor.
However, when subscribing to Vera/# I do not see any messages.
Any idea where I can troubleshoot/see logs for this plugin?

You can see the last published message on the Plugin Settings tab.
You can also monitor Vera's log or your MQTT Broker's log.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 06:19:08 am
I had the same issue. You may have the same problem I had...

The messages it sends are not persistent. You have to action something on the Vera while being subscribed to the MQTT topic so you can see it as the message is published.

Yeah that's correct, thanks Snaxmuppet
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on January 21, 2016, 06:22:14 am
Thanks, I'll check it out
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 06:36:41 am
I am finding that the messages are sent for a while and then they stop. Right now I left it half an hour and then switched on the monitored device and the MQTT message wasn't sent. Tried several times. Checked the Last Message on Setting on the device and the last message was from half an hour ago so it isn't sending the message.

However, while I am writing this I checked the watchdog and resaved it and then I switched it again and now it is working.

All a bit strange.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 06:38:53 am
bit strange, I haven't experienced any problems so far.
What type of device are we talking about?
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 07:13:01 am
It is a TZ88E Power Meter Socket.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 07:15:58 am
It is a TZ88E Power Meter Socket.

What Variables are you monitoring (that wasn't published to MQTT)?
I do have a few TKB on the bench that I'm using for testing purposes and haven't seen any problems so far...haven't tried with Power Meter though, only status changes.
Bottom line is I'm using variable watches and when *something* changes then it has to be triggered unless there's something wrong with the code in which case an error should be logged
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 07:50:34 am
Only monitoring urn:upnp-org:serviceId:SwitchPower1 with the Status variable.

It is working... just intermittently it seems although it seems pretty stable and consistent at the moment. It was just that long gap between switching that seemed to put it to sleep.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 21, 2016, 08:07:22 am
Only monitoring urn:upnp-org:serviceId:SwitchPower1 with the Status variable.

It is working... just intermittently it seems although it seems pretty stable and consistent at the moment. It was just that long gap between switching that seemed to put it to sleep.

Not really sure what to say TBH, that never happened to me even though i just tested it in a system that wasn't "touched" for two days.
Title: Re: MQTT Client Plugin
Post by: Snaxmuppet on January 21, 2016, 08:12:25 am
Fair enough... I shall monitor it now it is working (and still working) :)
Title: Re: MQTT Client Plugin
Post by: xAPPO on January 29, 2016, 01:15:36 pm
Hi,

  Well done for publishing this. I shall give it a try this weekend.  Just wondering if you plan to add support for subscribing to a topic at some time , for updates into Vera , or if the solution already meets your needs ?
Title: Re: MQTT Client Plugin
Post by: SchattenMann on January 29, 2016, 01:17:53 pm
To be honest that doesn't sound like something I would need since I'm moving all my logic away from Vera but I may take a look at it when and if I have the time...of course if any one wants to jump in and do it that would be great!
Title: Re: MQTT Client Plugin
Post by: cybrmage on January 29, 2016, 01:34:04 pm
Just wondering if you plan to add support for subscribing to a topic at some time , for updates into Vera

To be honest that doesn't sound like something I would need since I'm moving all my logic away from Vera but I may take a look at it when and if I have the time...of course if any one wants to jump in and do it that would be great!

I have actually worked on an MQTT client for my Caseta Connect plugin (based on a newer version of the paho client than yout plugin uses)... The Caseta Smartbridge uses an MQTT broker for status notifications. The problem is that to get timely subscription notifications (ie: instant status), you need asynchronous IO, not polled IO. I solved this by rewriting the paho client to use the Vera IO subsystem...

You are welcome to take a look at the Caseta Connect plugin (http://forum.micasaverde.com/index.php/topic,35577.0.html) to see how this was done... The Client is embedded in the L_CasetaConnect.lua file... and the incoming IO is in the I_CasetaConnect.xml file...

Title: Re: MQTT Client Plugin
Post by: xAPPO on January 30, 2016, 05:48:18 am
Great - I'll take a look this weekend hopefully

   I implemented an asynchronous TCP socket handler for my Vera xAP plugin - so I had that in my toolbox,  but if you've already got that integrated with the paho client that makes it so much easier...

Kevin
Title: Re: MQTT Client Plugin
Post by: gregl on March 09, 2016, 07:29:50 pm
Really great work creating this!

Any plans to be able to control via MQTT a device on Vera?

Title: Re: MQTT Client Plugin
Post by: SchattenMann on March 10, 2016, 04:48:53 am
Really great work creating this!

Any plans to be able to control via MQTT a device on Vera?

Not for now...still deciding on how to move forward
Title: Re: MQTT Client Plugin
Post by: vosmont on March 10, 2016, 06:42:00 am
You simply set which variables you want to monitor and all devices with those variables will publish status updates - you may then subscribe only the Topics you actually want to monitor but odds are if you need MQTT you're using something like node-red for all your logic and this is a huge help

Hello SchattenMann,
I'm discovering Node-red and MQTT.

I've played a little with "Node-red" and found that it's a bit hard to describe complex scenarios without coding it in functions.
Besides it seems that it's difficult to identify the Vera's devices in the UI when a lot are involved in a flow.

Can you make us a return on the use of MQTT with Node-red ?

Really great work creating this!

Any plans to be able to control via MQTT a device on Vera?

Not for now...still deciding on how to move forward

you can call action URL on device, or create a handler in your plugin to emulate a webservice (you will have more possibilities)
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on March 11, 2016, 07:27:15 am
My MQTT broker requires username / password authentication.
Would it be possible to add a username and password variable so authentication parameters can be passed to the broker for publishing messages?
Title: Re: MQTT Client Plugin
Post by: SchattenMann on March 11, 2016, 07:29:53 am

Can you make us a return on the use of MQTT with Node-red ?

Not sure I understood what you meant

Would it be possible to add a username and password variable so authentication parameters can be passed to the broker for publishing messages?

Hmm yes, I'd completely forgot about that...need to take a look at it
Title: Re: MQTT Client Plugin
Post by: vosmont on March 12, 2016, 08:02:48 am

Can you make us a return on the use of MQTT with Node-red ?

Not sure I understood what you meant
As you talked about Node-RED, I thought that you had tested MQTT with it.

Title: Re: MQTT Client Plugin
Post by: SchattenMann on March 31, 2016, 01:18:44 pm
As you talked about Node-RED, I thought that you had tested MQTT with it.

Well I do, that's pretty much the only reason why I've made this plugin :-)

All you need to do is to monitor the topic you want and react accordingly
Title: Re: MQTT Client Plugin
Post by: djassa1 on April 03, 2016, 07:41:40 am
Nice plugin, thanks. Exactly what i was looking for to connect different home automation boxes and send infos from my Veralite which is running UI5  :(

I was able to load the plugin and it is connecting to the broker correctly but I am unable to save watchers and alias probably because it's using a method only available in UI7.

Could you just tell me in the advanced settings of the plugin, how the variables are set? I have empty values like this (not saved):

mqttWatches   {}
mqttAlias   {}

Thanks for you help
Title: Re: MQTT Client Plugin
Post by: SchattenMann on April 04, 2016, 10:29:42 am
Nice plugin, thanks. Exactly what i was looking for to connect different home automation boxes and send infos from my Veralite which is running UI5  :(

I was able to load the plugin and it is connecting to the broker correctly but I am unable to save watchers and alias probably because it's using a method only available in UI7.

Could you just tell me in the advanced settings of the plugin, how the variables are set? I have empty values like this (not saved):

mqttWatches   {}
mqttAlias   {}

Thanks for you help


Actually I've installed it on my Vera Lite UI5 and noticed the same problem.
Looks like UI5 gets all messed up when displaying a JSON variable, no idea why and won't bother with it for now.
I've made a few tweaks that should make it work in UI5 (even though Vera won't display the values correctly)  - files attached.

Note: don't forget to clear browser cache and restart LUA after uploading new files.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on April 04, 2016, 10:31:43 am
I've also added a new variable mqttVeraIdentifier that acts as an unique identifier on the MQTT server.
It will also change the Topic where the message is posted to mqttVeraIdentifier/events/device ID or alias
Title: Re: MQTT Client Plugin
Post by: djassa1 on April 04, 2016, 07:07:02 pm
Nice plugin, thanks. Exactly what i was looking for to connect different home automation boxes and send infos from my Veralite which is running UI5  :(

I was able to load the plugin and it is connecting to the broker correctly but I am unable to save watchers and alias probably because it's using a method only available in UI7.

Could you just tell me in the advanced settings of the plugin, how the variables are set? I have empty values like this (not saved):

mqttWatches   {}
mqttAlias   {}

Thanks for you help


Actually I've installed it on my Vera Lite UI5 and noticed the same problem.
Looks like UI5 gets all messed up when displaying a JSON variable, no idea why and won't bother with it for now.
I've made a few tweaks that should make it work in UI5 (even though Vera won't display the values correctly)  - files attached.

Note: don't forget to clear browser cache and restart LUA after uploading new files.

Your modified plugin works for me, many thanks!
By the way the mqttwatches is looking now like this:

{"urn:micasaverde-com:serviceId:DoorLock1":{"Status":"Status"},"urn:upnp-org:serviceId:TemperatureSensor1":{"CurrentTemperature":"CurrentTemperature"}}

Because it's a json not on one line, UI5 is not able to display it. AltUI is able to read it.

Actually mqttVeraIdentifier  is defaulted to vera.

Title: Re: MQTT Client Plugin (enhancements contributed)
Post by: blacey on August 27, 2016, 01:37:41 pm
@SchattenMann - thanks for the awesome MQTT plugin...  I made several changes to better meet my use case.  First, I want to dump data from multiple residences into an InfluxDB time series database and then plot the data using Grafana.  So, each residence has a local MQTT broker running on an RPI that is securely bridged to a broker in my main home.  Each Vera reports to their local broker that then forwards the messages securely to the main broker where the data is collected and loaded into an InfluxDB instance. 

Here are the changes that I have made:


Here is an example of the output with the aforementioned changes:

Code: [Select]
Vera/Westshore/Events/138 {"DeviceId":138,"DeviceName":"Highland Lake","DeviceType":"urn:demo-micasaverde-com:device:weather:1","OldWindDirection":"SE","RoomId":0,"RoomName":"No Room","Time":1472319031,"WindDirection":"ESE"}
Vera/SeaSpray/Events/Heliotrope {"AzimuthRounded":"117.3","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAzimuthRounded":"117.2","RoomId":0,"RoomName":"No Room","Time":1472319039}
Vera/Westshore/Events/Cabinet Lights {"DeviceId":112,"DeviceName":"Cabinet Lights","DeviceType":"urn:schemas-upnp-org:device:DimmableRGBLight:2","OldWatts":"3.8","RoomId":3,"RoomName":"Kitchen","Time":1472319041,"Watts":"4.0"}
Vera/SeaSpray/Events/Heliotrope {"AzimuthRounded":"117.4","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAzimuthRounded":"117.3","RoomId":0,"RoomName":"No Room","Time":1472319054}
Vera/SeaSpray/Events/Heliotrope {"AltitudeRounded":"44.7","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAltitudeRounded":"44.6","RoomId":0,"RoomName":"No Room","Time":1472319069}
Vera/SeaSpray/Events/Heliotrope {"AzimuthRounded":"117.5","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAzimuthRounded":"117.4","RoomId":0,"RoomName":"No Room","Time":1472319084}
Vera/SeaSpray/Events/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"517.604","RoomId":2,"RoomName":"Living Room","Time":1472319085,"Watts":"612.301"}
Vera/SeaSpray/Events/17 {"DeviceId":17,"DeviceName":"Refrigerator Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"209.655","RoomId":3,"RoomName":"Kitchen","Time":1472319089,"Watts":"204.669"}
Vera/SeaSpray/Events/Heliotrope {"AltitudeRounded":"44.8","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAltitudeRounded":"44.7","RoomId":0,"RoomName":"No Room","Time":1472319099}
Vera/SeaSpray/Events/Heliotrope {"AzimuthRounded":"117.6","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAzimuthRounded":"117.5","RoomId":0,"RoomName":"No Room","Time":1472319114}
Vera/SeaSpray/Events/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"612.301","RoomId":2,"RoomName":"Living Room","Time":1472319114,"Watts":"451.097"}
Vera/SeaSpray/Events/23 {"DeviceId":23,"DeviceName":"IT Closet Energy MTR","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"144.253","RoomId":4,"RoomName":"Vacation Support","Time":1472319119,"Watts":"149.503"}
Vera/SeaSpray/Events/23 {"DeviceId":23,"DeviceName":"IT Closet Energy MTR","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"149.503","RoomId":4,"RoomName":"Vacation Support","Time":1472319121,"Watts":"148.678"}
Vera/SeaSpray/Events/Heliotrope {"AzimuthRounded":"117.7","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAzimuthRounded":"117.6","RoomId":0,"RoomName":"No Room","Time":1472319129}
Vera/SeaSpray/Events/Heliotrope {"AltitudeRounded":"44.9","DeviceId":62,"DeviceName":"Heliotrope","DeviceType":"urn:schemas-futzle-com:device:Heliotrope:1","OldAltitudeRounded":"44.8","RoomId":0,"RoomName":"No Room","Time":1472319129}
Vera/Westshore/Events/Cabinet Lights {"DeviceId":112,"DeviceName":"Cabinet Lights","DeviceType":"urn:schemas-upnp-org:device:DimmableRGBLight:2","OldWatts":"4.0","RoomId":3,"RoomName":"Kitchen","Time":1472319131,"Watts":"3.8"}
Vera/SeaSpray/Events/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"451.097","RoomId":2,"RoomName":"Living Room","Time":1472319145,"Watts":"538.100"}

Finally, I created a git repo from the plugin directory that tracks the evolution of the plugin in this thread.  If you don't know what git is, don't worry about it but if you do, when you download and unzip this archive, you can use git to review the changes and make controlled changes.  @SchatterMan, do you want to push this to GitHub?

Here is the git log for the plugin directory

Code: [Select]
bbl:vera-mqtt blacey$ git oneline
 2017855  Added support for MQTT broker authentication with username and password by Bruce B. Lacey 13 minutes ago
 5d3c7df  Upgraded lua mqtt client from 0.2 to the Eclipse Paho client 0.3 - https://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.lua.git/tree/paho by Bruce B. Lacey 40 minutes ago
 3d1379b  Added DeviceName, DeviceType, RoomId and RoomName to mqtt payload by Bruce B. Lacey 67 minutes ago
 c82c83a  Added mqttVeraIdentifier and added support for UI5 - by SchattenMan by Bruce B. Lacey 3 hours ago
 3589578  Original plugin written by SchattenMann on forum.micasaverde.com by Bruce B. Lacey 3 hours ago
Title: Re: MQTT Client Plugin (enhancements contributed part II)
Post by: blacey on August 27, 2016, 10:59:14 pm
Ok, I have made a couple more tweaks to improve downstream consumption of the messages.

1) I have changed the mqttVeraIdentifier to accept a pattern of context variables that will be substituted and used for the mqtt topic whenever a payload is published.  This allows each user to tailor the mqtt topic to meet their needs while maintaining backward compatibility with the original mqttVeraIdentifer functionality that @SchattenMann implemented.  For example, to mimic the current mqttVeraIdentifier semantics, one would use the pattern "Vera/Event/(Alias)". 

For my installation, I am using the mqttVeraIdentifier pattern "Vera/(SerialNumber)/(ServiceName)/(DeviceId)".  This topic name-spacing allows downstream mqtt subscribers to listen for all EnergeMetering1 variable change events by using the subscription "Vera/+/EnergyMetering1/#" or perhaps you want to subscribe to all messages from a specific device, you could use "Vera/+/+/+/42".  Maybe you want to route all messages from a specific vera from a remote broker to a central broker, you would use "Vera/5000797/#" for the topic specifier.  The following context variables are available for pattern substitution:

-- (SerialNumber) = Vera serial number as shown on home.getvera.com portal.
-- (City) = the city defined in the controller location tab
-- (ServiceId) = the service identifier
-- (ServiceName) = the name of the service
-- (DeviceId) = the device id
-- (DeviceName) = the device name / description
-- (Alias) = the device alias (legacy)
-- (Variable) = the variable changed under service for device
--
-- Legacy pattern = Vera/Event/(Alias)
-- Recommended = Vera/(SerialNumber)/(ServiceName)/(DeviceId)

2) I also added "Variable" to the payload so a downstream consumer can easily determine the name to use to retrieve the current value and old value from the JSON object.

3) Finally, DeviceName in the payload now uses the alias if defined on the "Alias" tab, otherwise it uses the description from luup.devices[].description which is equivalent to what is shown in the UI for a given device.

Here is a sample of output for two Veras reporting in from different locations:

Code: [Select]
Vera/50000797/EnergyMetering1/104 {"DeviceId":104,"DeviceName":"RPI 3 [ITS 1]","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"4.165","RoomId":4,"RoomName":"Supporting Elements","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352076,"Variable":"Watts","Watts":"3.682"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"430.191","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352101,"Variable":"Watts","Watts":"397.174"}
Vera/50000796/TemperatureSensor1/33 {"CurrentTemperature":"75","DeviceId":33,"DeviceName":"Thermostat","DeviceType":"urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1","OldCurrentTemperature":"74","RoomId":1,"RoomName":"Hallway","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1472352150,"Variable":"CurrentTemperature"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"352.119","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352208,"Variable":"Watts","Watts":"462.765"}
Vera/50000797/TemperatureSensor1/139 {"CurrentTemperature":"66.9","DeviceId":139,"DeviceName":"Outside Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","OldCurrentTemperature":"67.1","RoomId":0,"RoomName":"No Room","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1472352215,"Variable":"CurrentTemperature"}
Vera/50000797/TemperatureSensor1/140 {"CurrentTemperature":"59","DeviceId":140,"DeviceName":"Low Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","OldCurrentTemperature":"58","RoomId":0,"RoomName":"No Room","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1472352215,"Variable":"CurrentTemperature"}
Vera/50000796/EnergyMetering1/17 {"DeviceId":17,"DeviceName":"Refrigerator Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"205.402","RoomId":3,"RoomName":"Kitchen","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352222,"Variable":"Watts","Watts":"3.792"}
Vera/50000796/SecuritySensor1/55 {"DeviceId":55,"DeviceName":"_Motion Sensor","DeviceType":"urn:schemas-micasaverde-com:device:MotionSensor:1","OldTripped":"1","RoomId":1,"RoomName":"Hallway","ServiceId":"urn:micasaverde-com:serviceId:SecuritySensor1","Time":1472352230,"Tripped":"0","Variable":"Tripped"}
Vera/50000796/EnergyMetering1/82 {"DeviceId":82,"DeviceName":"iMac","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"6.178","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352293,"Variable":"Watts","Watts":"63.585"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"547.773","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352298,"Variable":"Watts","Watts":"432.081"}
Vera/50000796/SecuritySensor1/55 {"DeviceId":55,"DeviceName":"_Motion Sensor","DeviceType":"urn:schemas-micasaverde-com:device:MotionSensor:1","OldTripped":"0","RoomId":1,"RoomName":"Hallway","ServiceId":"urn:micasaverde-com:serviceId:SecuritySensor1","Time":1472352313,"Tripped":"1","Variable":"Tripped"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"432.081","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352328,"Variable":"Watts","Watts":"343.394"}
Vera/50000796/TemperatureSensor1/84 {"CurrentTemperature":"63.4","DeviceId":84,"DeviceName":"Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","OldCurrentTemperature":"64.6","RoomId":0,"RoomName":"No Room","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1472352367,"Variable":"CurrentTemperature"}
Vera/50000796/HumiditySensor1/87 {"CurrentLevel":"72","DeviceId":87,"DeviceName":"Humidity","DeviceType":"urn:schemas-micasaverde-com:device:HumiditySensor:1","OldCurrentLevel":"70","RoomId":0,"RoomName":"No Room","ServiceId":"urn:micasaverde-com:serviceId:HumiditySensor1","Time":1472352367,"Variable":"CurrentLevel"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"343.394","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352388,"Variable":"Watts","Watts":"541.739"}
Vera/50000796/EnergyMetering1/23 {"DeviceId":23,"DeviceName":"IT Closet Energy MTR","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"146.663","RoomId":4,"RoomName":"Vacation Support","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352411,"Variable":"Watts","Watts":"151.761"}
Vera/50000796/EnergyMetering1/23 {"DeviceId":23,"DeviceName":"IT Closet Energy MTR","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"151.761","RoomId":4,"RoomName":"Vacation Support","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352413,"Variable":"Watts","Watts":"151.536"}
Vera/50000796/EnergyMetering1/41 {"DeviceId":41,"DeviceName":"Home Theater Energy","DeviceType":"urn:schemas-upnp-org:device:BinaryLight:1","OldWatts":"541.739","RoomId":2,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1472352448,"Variable":"Watts","Watts":"481.798"}

And here is the git change log for the two additional for the plugin repo attached:

Code: [Select]
git log --oneline
8bb08e2 DeviceName in payload is now set to an alias if defined, otherwise the Vera Device description from luup.devices[].description
af51f9f Extended mqttVeraIdentifer to be expressed as a pattern of context variables for more flexible topic definition

At this point, I am ready to start developing the downstream consumer to pump the Vera event data into InfluxDB (as time permits) and might return here if I find that I need to make additional changes to @SchattenMann's great prior art.  I hope others find these few additions useful.
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on August 28, 2016, 04:33:29 am
Thanks for the authentication part! Much appreciated.
Title: Re: MQTT Client Plugin
Post by: SchattenMann on August 28, 2016, 12:48:23 pm
Hey blacey,

Fantastic work, congrats!

I'd say the number one request has been to make Vera subscribe topics so that one can control Vera events via MQTT.
Not something I need myself to be honest, but though you should know
Title: Re: MQTT Client Plugin
Post by: blacey on August 28, 2016, 12:55:13 pm
Thanks for the authentication part! Much appreciated.

Have you had a chance to test it?  I'm using unauthenticated broker connections internally over port 1883 with client-cert base authentication over TLS/SSL port 8883 for the remote bridged brokers so the Vera clients don't require a username and password.  If you find that it works, please post your results here.
Title: Re: MQTT Client Plugin
Post by: blacey on August 28, 2016, 01:00:51 pm
I'd say the number one request has been to make Vera subscribe topics so that one can control Vera events via MQTT.
Not something I need myself to be honest, but though you should know

Right now, I just want to collect sensor data from multiple sites so I, not unlike you, will probably leave that to next guy/gal who stops by and takes the bull by the horns.  Even though I don't need authentication either, I added it for others because it was pretty straight-forward to do by upgrading to the newer lua mqqt client library.  Thanks again for doing the heavy-lifting to produce the mqtt plugin for Vera.  Do you want to push the source up to GitHub?
Title: Re: MQTT Client Plugin
Post by: SchattenMann on August 28, 2016, 03:13:42 pm
here it is - https://github.com/jonferreira/vera-mqtt

thanks for the help!
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on August 29, 2016, 02:33:38 am
Authentication with username/password works over port 1883 unencrypted.
Title: Re: MQTT Client Plugin
Post by: blacey on August 30, 2016, 10:18:00 pm
here it is - https://github.com/jonferreira/vera-mqtt

thanks for the help!

Excellent!  I had to travel today but I have another small improvement (two line change) that I will push to Github.  The change is to accurately represent the changed variable's type information in the JSON representation.  Luup apparently returns floats as strings (e.g. Watts) so this change ensures that all changed-variables that contain numeric representations in the string will be represented as ints or floats.  The impetus is a more accurate representation of the type information when persisting to a database such as InfluxDB.
Title: Re: MQTT Client Plugin
Post by: blacey on August 30, 2016, 10:24:17 pm
Authentication with username/password works over port 1883 unencrypted.

Excellent - thanks for verifying!  I just removed the **untested** qualifier from the earlier post that cited the authentication enhancement.  ;)  The paho client isn't capable of establishing a TLS/SSL connection. 
Title: Re: MQTT Client Plugin ***Soup-to-nuts results***
Post by: blacey on August 30, 2016, 11:02:27 pm
Ok, so here are some initial results that leverage the MQTT Client. 

Setup:


Everything seems to be working well.  The following is the node-red flow and a couple of sample dashboards.
Title: Re: MQTT Client Plugin
Post by: blacey on September 04, 2016, 08:42:47 am
For anyone who is currently using the plugin, there is a new version on GitHub that significantly improves reliability.  Here is a list of the changes.

Code: [Select]
commit 89d0dac17e610ac2c1babf01ed9a309782888670
Author: Bruce Lacey
Date:   Sun Sep 4 08:11:21 2016 -0400

    Refactored to improve connection state management and logging consistency.
   
      - Simplified connection state-machine to greatly improve connection management
        robustness with extensibility for handling subscriptions in the future
      - MQTT client connection resources are ?cleanly? reclaimed if a broker-initiated
        disconnect occurrs
      - Fixed issue that prevented mqtt broker pings after reconnect (pings need to resume too)
      - MQTT client KEEP_ALIVE set properly to ensure MQTT pings are issued within
        the 1.5 MQTT 3.1 time_interval requirement to reduce broker-initiated disconnects
      - Enable multiple vera connections to a single broker by qualifying the connection
        id with the controller serial number
      - All logging is performed either via local debug() and log() functions
      - Last message no longer displays extraneous topic pattern variables
      - Set ?debug? to false to reduce logging for normal users (perhaps this should
        be exposed to the UI)?
      - General code cleanup/reformatting
   
    Fixes #3, #4

commit 37b9c319a728b23b5d41022a97f8f7587a6957a9
Author: Bruce Lacey
Date:   Sun Sep 4 08:08:36 2016 -0400

    Upgraded JSON library from version 20131118.9 to 20160728.17

I tested this extensively by stopping/starting the broker, etc. and the client will now always reliably connect and resume sending variable updates to the broker.
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 04, 2016, 12:00:17 pm
The client does not connect anymore (disconnected) with the last version. This was not the case before.
Title: Re: MQTT Client Plugin
Post by: blacey on September 04, 2016, 02:33:49 pm
The client does not connect anymore (disconnected) with the last version. This was not the case before.

Which broker are you connecting to?

Please post the SensorMqtt1: log messages here so I can help diagnose/troubleshoot.  When you reviewing the log messages, we need to confirm the connection parameters (i.e. server ip, server port, username).

Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 05, 2016, 02:44:21 am
I'm connecting to mosquitto.
before uploading the last file the connection went well.

Below my log

Code: [Select]
# cat /tmp/log/cmh/LuaUPnP.log | grep SensorMqtt1

06 09/05/16 7:16:43.224 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"ArmedTripped\":0,\"DeviceId\":114,\"DeviceName\":\"MKT Garagepoort\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:DoorSensor:1\",\"OldArmedTripped\":1,\"RoomId\":1,\"RoomName\":\"1-Alarmsysteem\",\"ServiceId\":\"urn:micasaverde-com:serviceId:SecuritySensor1\",\"Time\":1473052602,\"Variable\":\"ArmedTripped\"}","Topic":"vera/MKT Garagepoort/ArmedTripped"} now: {"Payload":"{\"DeviceId\":114,\"DeviceName\":\"MKT Garagepoort\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:DoorSensor:1\",\"OldTripped\":1,\"RoomId\":1,\"RoomName\":\"1-Alarmsysteem\",\"ServiceId\":\"urn:micasaverde-com:serviceId:SecuritySensor1\",\"Time\":1473052603,\"Tripped\":0,\"Variable\":\"Tripped\"}","Topic":"vera/MKT Garagepoort/Tripped"} #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x35670680>
06 09/05/16 8:17:02.452 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Disconnected now: Connected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
06 09/05/16 8:17:02.517 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
06 09/05/16 8:17:02.521 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"DeviceId\":114,\"DeviceName\":\"MKT Garagepoort\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:DoorSensor:1\",\"OldTripped\":1,\"RoomId\":1,\"RoomName\":\"1-Alarmsysteem\",\"ServiceId\":\"urn:micasaverde-com:serviceId:SecuritySensor1\",\"Time\":1473052603,\"Tripped\":0,\"Variable\":\"Tripped\"}","Topic":"vera/MKT Garagepoort/Tripped"} now: {"Payload":"{\"DeviceId\":195,\"DeviceName\":\"Presence\",\"DeviceType\":\"urn:schemas-dcineco-com:device:MSwitch195:1\",\"OldStatus2\":0,\"RoomId\":12,\"RoomName\":\"10-Location\",\"ServiceId\":\"urn:dcineco-com:serviceId:MSwitch1\",\"Status2\":1,\"Time\":1473056222,\"Variable\":\"Status2\"}","Topic":"vera/Presence/Status2"} #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
06 09/05/16 8:17:02.601 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
06 09/05/16 8:17:02.604 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
06 09/05/16 8:17:02.679 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"DeviceId\":195,\"DeviceName\":\"Presence\",\"DeviceType\":\"urn:schemas-dcineco-com:device:MSwitch195:1\",\"OldStatus2\":0,\"RoomId\":12,\"RoomName\":\"10-Location\",\"ServiceId\":\"urn:dcineco-com:serviceId:MSwitch1\",\"Status2\":1,\"Time\":1473056222,\"Variable\":\"Status2\"}","Topic":"vera/Presence/Status2"} now: {"Payload":"{\"DeviceId\":18,\"DeviceName\":\"House Modes Plugin\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:HouseModes:1\",\"HMode\":1,\"OldHMode\":2,\"RoomId\":3,\"RoomName\":\"6-System\",\"ServiceId\":\"urn:micasaverde-com:serviceId:HouseModes1\",\"Time\":1473056222,\"Variable\":\"HMode\"}","Topic":"vera/House Modes Plugin/HMode"} #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2b376310>
50 09/05/16 8:27:02.829 luup_log:188: SensorMqtt plugin: loading library L_SensorMqtt1 ... <0x2c4df680>
50 09/05/16 8:27:03.054 luup_log:188: SensorMqtt plugin: library L_SensorMqtt1 loaded <0x2c4df680>
06 09/05/16 8:27:03.157 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x2c4df680>
06 09/05/16 8:27:03.163 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Disconnected now: Connected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2c4df680>
06 09/05/16 8:27:03.185 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2c4df680>
06 09/05/16 8:27:08.101 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x334df680>
06 09/05/16 8:27:08.103 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x334df680>
Title: Re: MQTT Client Plugin
Post by: blacey on September 05, 2016, 08:53:15 am
I'm connecting to mosquitto.
before uploading the last file the connection went well.

Below my log

# cat /tmp/log/cmh/LuaUPnP.log | grep SensorMqtt1

Thanks.  I appreciate the testing...  I'm also using mosquito 1.4.8 for my testing and have two Vera+ units running UI7 and one Vera3 running UI5 and all are reporting over mqtt very reliably.

1.  Based upon your logs, I believe it is connecting and delivering payloads but reporting the "connection" status incorrectly.
2.  While I'm not seeing this issue on my installs, I just made one small update to the plugin to pre-allocate the "connection" status service variables to eliminate the __LEAK__ warning on UI5 and perhaps resolve the inconsistent status reporting that you are seeing.
3.  Please upgrade to the latest plugin, INCLUDING uploading/refreshing the dependencies because they were updated too.
4, Then grep for SensorMqtt - not SensorMqtt1 - and reload the luup engine.  Copy the connection status and at least one variable change update.

Here is an example of my output, albeit on UI5:

Code: [Select]
$ ssh vera.home tail -f /var/log/cmh/LuaUPnP.log | grep SensorMqtt
09 09/05/16 8:44:05.233 JobHandler_LuaUPnP::Run device 53 MQTT Sender room 4 type urn:schemas-sensor-mqtt-se:device:SensorMqtt:1 id  parent 0/0xdadc30 upnp: 0 <0x2b27e000>
50 09/05/16 8:44:07.104 luup_log:53: SensorMqtt plugin: loading library L_SensorMqtt1 ... <0x2bbb1680>
50 09/05/16 8:44:07.175 luup_log:53: SensorMqtt plugin: library L_SensorMqtt1 loaded <0x2bbb1680>
50 09/05/16 8:44:07.176 luup_log:53: SensorMqtt:  Initializing SensorMqtt <0x2bbb1680>
06 09/05/16 8:44:07.203 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2bbb1680>
50 09/05/16 8:44:07.204 luup_log:53: SensorMqtt:  Connect to MQTT, mqttServerIp: 10.0.1.220 mqttServerPort: 1883 <0x2bbb1680>
50 09/05/16 8:44:07.208 luup_log:53: SensorMqtt:  Successfully connected to broker: 10.0.1.220 on port 1883 <0x2bbb1680>
50 09/05/16 8:44:07.210 luup_log:53: SensorMqtt:  MQTT connection status changed from "Disconnected" to "Connected" <0x2bbb1680>
06 09/05/16 8:44:07.211 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Connected #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x2bbb1680>
06 09/05/16 8:44:07.211 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2bbb1680>

06 09/05/16 8:45:37.913 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"CurrentTemperature\":60,\"DeviceId\":47,\"DeviceName\":\"Carport Temp Sensor\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:TemperatureSensor:1\",\"OldCurrentTemperature\":59,\"RoomId\":2,\"RoomName\":\"Outside\",\"ServiceId\":\"urn:upnp-org:serviceId:TemperatureSensor1\",\"Time\":1473078975,\"Variable\":\"CurrentTemperature\"}","Topic":"Vera/30002905/TemperatureSensor1/47"} now: {"Payload":"{\"DeviceId\":29,\"DeviceName\":\"Exterior Cameras (Power)\",\"DeviceType\":\"urn:schemas-upnp-org:device:BinaryLight:1\",\"OldTarget\":1,\"RoomId\":4,\"RoomName\":\"Supporting Devices & Scenes\",\"ServiceId\":\"urn:upnp-org:serviceId:SwitchPower1\",\"Target\":0,\"Time\":1473079537,\"Variable\":\"Target\"}","Topic":"Vera/30002905/SwitchPower1/29"} #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2d9b1680>
06 09/05/16 8:45:38.123 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"DeviceId\":29,\"DeviceName\":\"Exterior Cameras (Power)\",\"DeviceType\":\"urn:schemas-upnp-org:device:BinaryLight:1\",\"OldTarget\":1,\"RoomId\":4,\"RoomName\":\"Supporting Devices & Scenes\",\"ServiceId\":\"urn:upnp-org:serviceId:SwitchPower1\",\"Target\":0,\"Time\":1473079537,\"Variable\":\"Target\"}","Topic":"Vera/30002905/SwitchPower1/29"} now: {"Payload":"{\"DeviceId\":29,\"DeviceName\":\"Exterior Cameras (Power)\",\"DeviceType\":\"urn:schemas-upnp-org:device:BinaryLight:1\",\"OldStatus\":1,\"RoomId\":4,\"RoomName\":\"Supporting Devices & Scenes\",\"ServiceId\":\"urn:upnp-org:serviceId:SwitchPower1\",\"Status\":0,\"Time\":1473079538,\"Variable\":\"Status\"}","Topic":"Vera/30002905/SwitchPower1/29"} #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2b9b1680>
06 09/05/16 8:48:15.157 Device_Variable::m_szValue_set device: 53 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttLastMessage was: {"Payload":"{\"DeviceId\":29,\"DeviceName\":\"Exterior Cameras (Power)\",\"DeviceType\":\"urn:schemas-upnp-org:device:BinaryLight:1\",\"OldStatus\":1,\"RoomId\":4,\"RoomName\":\"Supporting Devices & Scenes\",\"ServiceId\":\"urn:upnp-org:serviceId:SwitchPower1\",\"Status\":0,\"Time\":1473079538,\"Variable\":\"Status\"}","Topic":"Vera/30002905/SwitchPower1/29"} now: {"Payload":"{\"CurrentLevel\":90,\"DeviceId\":46,\"DeviceName\":\"Carport Motion Sensor\",\"DeviceType\":\"urn:schemas-micasaverde-com:device:MotionSensor:1\",\"OldCurrentLevel\":89,\"RoomId\":2,\"RoomName\":\"Outside\",\"ServiceId\":\"urn:micasaverde-com:serviceId:HumiditySensor1\",\"Time\":1473079695,\"Variable\":\"CurrentLevel\"}","Topic":"Vera/30002905/HumiditySensor1/46"} #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2b9b1680>

Thanks again for the testing and feedback.
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 05, 2016, 09:51:37 am
Thanks a lot Blacey!
The connection still reports "disconnected".
After reloading LUUP it becomes connected for a second and then returns disconnected.

Below some log lines
Code: [Select]
06 09/05/16 15:43:55.102 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32f37680>
06 09/05/16 15:43:55.103 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32f37680>
root@MiOS_30105293:/tmp/log/cmh# cat LuaUPnP.log | grep SensorMqtt
09 09/05/16 15:42:51.361 JobHandler_LuaUPnP::Run device 188 MQTT Publish room 4 type urn:schemas-sensor-mqtt-se:device:SensorMqtt:1 cat 3:-1 id  parent 0/0x9fa4b0 upnp: 0 plugin:0 pnp:0 mac: ip: <0x2b9e3310>
09 09/05/16 15:43:23.792 JobHandler_LuaUPnP::Run device 188 MQTT Publish room 4 type urn:schemas-sensor-mqtt-se:device:SensorMqtt:1 cat 3:-1 id  parent 0/0x101d4b0 upnp: 0 plugin:0 pnp:0 mac: ip: <0x2b4f6310>
50 09/05/16 15:43:49.819 luup_log:188: SensorMqtt plugin: loading library L_SensorMqtt1 ... <0x2bf37680>
50 09/05/16 15:43:49.947 luup_log:188: SensorMqtt plugin: library L_SensorMqtt1 loaded <0x2bf37680>
50 09/05/16 15:43:49.948 luup_log:188: SensorMqtt:  Initializing SensorMqtt <0x2bf37680>
06 09/05/16 15:43:49.987 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x2bf37680>
50 09/05/16 15:43:49.988 luup_log:188: SensorMqtt:  Connect to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883 <0x2bf37680>
50 09/05/16 15:43:49.991 luup_log:188: SensorMqtt:  Successfully connected to broker: 192.168.1.40 on port 1883 <0x2bf37680>
50 09/05/16 15:43:49.992 luup_log:188: SensorMqtt:  MQTT connection status changed from "Disconnected" to "Connected" <0x2bf37680>
06 09/05/16 15:43:49.993 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Disconnected now: Connected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2bf37680>
06 09/05/16 15:43:50.016 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2bf37680>
50 09/05/16 15:43:55.101 luup_log:188: SensorMqtt:  MQTT connection status changed from "Connected" to "Disconnected" <0x32f37680>
06 09/05/16 15:43:55.102 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32f37680>
06 09/05/16 15:43:55.103 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x32f37680>
09 09/05/16 15:49:45.408 JobHandler_LuaUPnP::Run device 188 MQTT Publish room 4 type urn:schemas-sensor-mqtt-se:device:SensorMqtt:1 cat 3:-1 id  parent 0/0xeb94b0 upnp: 0 plugin:0 pnp:0 mac: ip: <0x2b731310>
50 09/05/16 15:50:11.513 luup_log:188: SensorMqtt plugin: loading library L_SensorMqtt1 ... <0x2c173680>
50 09/05/16 15:50:11.627 luup_log:188: SensorMqtt plugin: library L_SensorMqtt1 loaded <0x2c173680>
50 09/05/16 15:50:11.637 luup_log:188: SensorMqtt:  Initializing SensorMqtt <0x2c173680>
06 09/05/16 15:50:11.718 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:1 <0x2c173680>
50 09/05/16 15:50:11.719 luup_log:188: SensorMqtt:  Connect to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883 <0x2c173680>
50 09/05/16 15:50:11.728 luup_log:188: SensorMqtt:  Successfully connected to broker: 192.168.1.40 on port 1883 <0x2c173680>
50 09/05/16 15:50:11.730 luup_log:188: SensorMqtt:  MQTT connection status changed from "Disconnected" to "Connected" <0x2c173680>
06 09/05/16 15:50:11.730 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Disconnected now: Connected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2c173680>
06 09/05/16 15:50:11.763 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x2c173680>
50 09/05/16 15:50:16.103 luup_log:188: SensorMqtt:  MQTT connection status changed from "Connected" to "Disconnected" <0x33173680>
06 09/05/16 15:50:16.104 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x33173680>
06 09/05/16 15:50:16.106 Device_Variable::m_szValue_set device: 188 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 1 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x33173680>
Title: Re: MQTT Client Plugin
Post by: blacey on September 05, 2016, 11:07:10 am
Thanks a lot Blacey!
The connection still reports "disconnected".
After reloading LUUP it becomes connected for a second and then returns disconnected.

Ok, I just pushed another update that will report debug log messages when Verbose logging is enabled on the Vera.  Please do the following so we can figure this out:

1.  Enable Verbose logging on your Vera Controller
2.  Install the latest plugin (only the L_SensorMqtt1.lua and I_SensorMqtt1.xml changed)
3.  Collect logs using
Code: [Select]
grep '\(^01\|^02\|^35\|^50\).*SensorMqtt'4.  Report results here.  Note, it will be easier to read the logs if you post them as code blocks.

Also, please provide your Mosquitto and Vera Firmware versions.

Thanks.  Looking forward to figuring out this mystery.

Here is a sample of what we should see:
Code: [Select]
50 09/05/16 11:38:03.143 luup_log:53: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x2b951680>
50 09/05/16 11:38:03.208 luup_log:53: SensorMqtt: Plugin module L_SensorMqtt1 loaded <0x2b951680>
50 09/05/16 11:38:03.209 luup_log:53: SensorMqtt: Initializing SensorMqtt <0x2b951680>
50 09/05/16 11:38:03.237 luup_log:53: SensorMqtt: Connecting to MQTT, mqttServerIp: 10.0.1.220 mqttServerPort: 1883... <0x2b951680>
50 09/05/16 11:38:03.239 luup_log:53: SensorMqtt: Successfully connected to broker: 10.0.1.220 on port 1883 <0x2b951680>
35 09/05/16 11:38:03.242 luup_log:53: SensorMqtt: setConnectionStatus:  currentStatus = true previousStatus = false <0x2b951680>
50 09/05/16 11:38:03.242 luup_log:53: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2b951680>
35 09/05/16 11:38:03.261 luup_log:53: SensorMqtt: ************************************************ MQTT Settings ************************************************ <0x2b951680>
35 09/05/16 11:38:03.261 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:HVAC_OperatingState1 on variable ModeState with label ModeState <0x2b951680>
35 09/05/16 11:38:03.262 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:HVAC_OperatingState1 on variable ModeStateForEnergy with label ModeStateForEnergy <0x2b951680>
35 09/05/16 11:38:03.263 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:HVAC_UserOperatingMode1 on variable ModeStatus with label ModeStatus <0x2b951680>
35 09/05/16 11:38:03.264 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:HVAC_UserOperatingMode1 on variable ModeTarget with label ModeTarget <0x2b951680>
35 09/05/16 11:38:03.265 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:HVAC_UserOperatingMode1 on variable EnergyModeStatus with label EnergyModeStatus <0x2b951680>
35 09/05/16 11:38:03.266 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:HVAC_UserOperatingMode1 on variable EnergyModeTarget with label EnergyModeTarget <0x2b951680>
35 09/05/16 11:38:03.267 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:TemperatureSensor1 on variable CurrentTemperature with label CurrentTemperature <0x2b951680>
35 09/05/16 11:38:03.270 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:EnergyMetering1 on variable Watts with label Watts <0x2b951680>
35 09/05/16 11:38:03.275 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:EnergyMetering1 on variable UserSuppliedWattage with label UserSuppliedWattage <0x2b951680>
35 09/05/16 11:38:03.281 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:GenericSensor1 on variable CurrentLevel with label CurrentLevel <0x2b951680>
35 09/05/16 11:38:03.282 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:SwitchPower1 on variable Status with label Status <0x2b951680>
35 09/05/16 11:38:03.289 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:SwitchPower1 on variable Target with label Target <0x2b951680>
35 09/05/16 11:38:03.296 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:HaDevice1 on variable BatteryLevel with label BatteryLevel <0x2b951680>
35 09/05/16 11:38:03.308 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:HumiditySensor1 on variable CurrentLevel with label CurrentLevel <0x2b951680>
35 09/05/16 11:38:03.310 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:TemperatureSetpoint1_Cool on variable CurrentSetpoint with label CurrentSetpoint <0x2b951680>
35 09/05/16 11:38:03.311 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:TemperatureSetpoint1_Cool on variable SetpointTarget with label SetpointTarget <0x2b951680>
35 09/05/16 11:38:03.312 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:LightSensor1 on variable CurrentLevel with label CurrentLevel <0x2b951680>
35 09/05/16 11:38:03.313 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable ArmedTripped with label ArmedTripped <0x2b951680>
35 09/05/16 11:38:03.316 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Tripped with label Tripped <0x2b951680>
35 09/05/16 11:38:03.318 luup_log:53: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Armed with label Armed <0x2b951680>
35 09/05/16 11:38:03.320 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:TemperatureSetpoint1_Heat on variable CurrentSetpoint with label CurrentSetpoint <0x2b951680>
35 09/05/16 11:38:03.321 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:TemperatureSetpoint1_Heat on variable SetpointTarget with label SetpointTarget <0x2b951680>
35 09/05/16 11:38:03.322 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:Dimming1 on variable LoadLevelTarget with label LoadLevelTarget <0x2b951680>
35 09/05/16 11:38:03.325 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:Dimming1 on variable LoadLevelStatus with label LoadLevelStatus <0x2b951680>
35 09/05/16 11:38:03.328 luup_log:53: SensorMqtt: Watching urn:upnp-org:serviceId:HVAC_FanOperatingMode1 on variable Mode with label Mode <0x2b951680>
35 09/05/16 11:38:49.913 luup_log:53: SensorMqtt: Watch event - device: 19 variable: Watts value 40 => 36 <0x2b751680>
50 09/05/16 11:38:49.917 luup_log:53: SensorMqtt: Sending [Living Room Lamp] Watts changed to 36 from 40 on topic Vera/30002905/EnergyMetering1/19 <0x2b751680>
35 09/05/16 11:38:49.918 luup_log:53: SensorMqtt: Publish topic: Vera/30002905/EnergyMetering1/19 message:{"DeviceId":19,"DeviceName":"Living Room Lamp","DeviceType":"urn:schemas-upnp-org:device:DimmableLight:1","OldWatts":40,"RoomId":8,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1473089929,"Variable":"Watts","Watts":36} <0x2b751680>
35 09/05/16 11:38:49.925 luup_log:53: SensorMqtt: Watch event - device: 19 variable: LoadLevelStatus value 40 => 36 <0x2b751680>
50 09/05/16 11:38:49.929 luup_log:53: SensorMqtt: Sending [Living Room Lamp] LoadLevelStatus changed to 36 from 40 on topic Vera/30002905/Dimming1/19 <0x2b751680>
35 09/05/16 11:38:49.929 luup_log:53: SensorMqtt: Publish topic: Vera/30002905/Dimming1/19 message:{"DeviceId":19,"DeviceName":"Living Room Lamp","DeviceType":"urn:schemas-upnp-org:device:DimmableLight:1","LoadLevelStatus":36,"OldLoadLevelStatus":40,"RoomId":8,"RoomName":"Living Room","ServiceId":"urn:upnp-org:serviceId:Dimming1","Time":1473089929,"Variable":"LoadLevelStatus"} <0x2b751680>
35 09/05/16 11:38:51.282 luup_log:53: SensorMqtt: Watch event - device: 19 variable: Watts value 36 => 5 <0x2b751680>
50 09/05/16 11:38:51.285 luup_log:53: SensorMqtt: Sending [Living Room Lamp] Watts changed to 5 from 36 on topic Vera/30002905/EnergyMetering1/19 <0x2b751680>
35 09/05/16 11:38:51.286 luup_log:53: SensorMqtt: Publish topic: Vera/30002905/EnergyMetering1/19 message:{"DeviceId":19,"DeviceName":"Living Room Lamp","DeviceType":"urn:schemas-upnp-org:device:DimmableLight:1","OldWatts":36,"RoomId":8,"RoomName":"Living Room","ServiceId":"urn:micasaverde-com:serviceId:EnergyMetering1","Time":1473089931,"Variable":"Watts","Watts":5} <0x2b751680>
35
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 06, 2016, 02:57:17 am
Below the requested info:
Vera 3 with firmware 1.7.855
Mosquitto version 1.4.10 on Raspberry Pi 2B

Code: [Select]
cat /tmp/log/cmh/LuaUPnP.log | grep '\(^01\|^02\|^35\|^50\).*SensorMqtt'
50 09/06/16 8:52:37.021 luup_log:188: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x2b9d3680>
50 09/06/16 8:52:37.187 luup_log:188: SensorMqtt: Plugin module L_SensorMqtt1 loaded <0x2b9d3680>
50 09/06/16 8:52:37.187 luup_log:188: SensorMqtt: Initializing SensorMqtt <0x2b9d3680>
50 09/06/16 8:52:37.230 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x2b9d3680>
50 09/06/16 8:52:37.233 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x2b9d3680>
50 09/06/16 8:52:37.235 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2b9d3680>
50 09/06/16 8:52:37.312 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x2b9d3680>
50 09/06/16 8:54:10.764 luup_log:188: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x2b5a1680>
50 09/06/16 8:54:10.887 luup_log:188: SensorMqtt: Plugin module L_SensorMqtt1 loaded <0x2b5a1680>
50 09/06/16 8:54:10.908 luup_log:188: SensorMqtt: Initializing SensorMqtt <0x2b5a1680>
50 09/06/16 8:54:10.957 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x2b5a1680>
35 09/06/16 8:54:10.958 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x2b5a1680>
50 09/06/16 8:54:10.960 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x2b5a1680>
35 09/06/16 8:54:10.962 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = true previousStatus = false <0x2b5a1680>
50 09/06/16 8:54:10.963 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2b5a1680>
35 09/06/16 8:54:11.006 luup_log:188: SensorMqtt: ************************************************ MQTT Settings ************************************************ <0x2b5a1680>
35 09/06/16 8:54:11.006 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable ArmedTripped with label ArmedTripped <0x2b5a1680>
35 09/06/16 8:54:11.046 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Tripped with label Tripped <0x2b5a1680>
35 09/06/16 8:54:11.055 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Armed with label Armed <0x2b5a1680>
35 09/06/16 8:54:11.066 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:HouseModes1 on variable HMode with label HMode <0x2b5a1680>
35 09/06/16 8:54:11.068 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:HouseModes1 on variable Message with label Message <0x2b5a1680>
35 09/06/16 8:54:11.081 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status3 with label Status3 <0x2b5a1680>
35 09/06/16 8:54:11.105 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status1 with label Status1 <0x2b5a1680>
35 09/06/16 8:54:11.107 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status4 with label Status4 <0x2b5a1680>
35 09/06/16 8:54:11.108 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status2 with label Status2 <0x2b5a1680>
35 09/06/16 8:54:11.114 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventTime with label LastLogEventTime <0x2b5a1680>
35 09/06/16 8:54:11.122 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventUser with label LastLogEventUser <0x2b5a1680>
35 09/06/16 8:54:11.129 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEvent with label LastLogEvent <0x2b5a1680>
35 09/06/16 8:54:11.138 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventPartition with label LastLogEventPartition <0x2b5a1680>
35 09/06/16 8:54:11.148 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x2b5a1680>
35 09/06/16 8:54:11.148 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = true <0x2b5a1680>
50 09/06/16 8:54:11.149 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x2b5a1680>
35 09/06/16 8:54:16.103 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x325a1680>
35 09/06/16 8:54:16.104 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = false <0x325a1680>
35 09/06/16 8:54:21.103 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x325a1680>
35 09/06/16 8:54:21.104 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = false <0x325a1680>
35 09/06/16 8:54:26.104 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x325a1680>
35 09/06/16 8:54:26.104 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = false <0x325a1680>
35 09/06/16 8:54:31.012 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x325a1680>
35 09/06/16 8:54:31.013 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = false <0x325a1680>
35 09/06/16 8:54:36.103 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x325a1680>
35 09/06/16 8:54:36.104 luup_log:188: SensorMqtt: setConnectionStatus:  currentStatus = false previousStatus = false <0x325a1680>
Title: Re: MQTT Client Plugin
Post by: blacey on September 06, 2016, 09:02:22 am
Below the requested info:
Vera 3 with firmware 1.7.855
Mosquitto version 1.4.10 on Raspberry Pi 2B

Thanks - this is very helpful. The logs that confirm it is indeed an issue with the actual connection and not an issue with incorrect connection status reporting.  The way the connection state machine now works is that during plugin initialization it will attempt to connect to the broker and then process mqtt events in 5 second intervals (adequate for a persistent connection without any active subscriptions).  If the connection goes down, the client will continue to check for any new mqtt events but won't try to reconnect to the broker until it needs to publish a message; I did this intentionally because currently the client is a publish-only client but we are considering extending the client to subscribe to commands received via mqtt).  The "Connection down" is reported in 5 second intervals so that is what we are seeing (every attempt to check for mqtt events fails with the connection down). 

The only difference between our setups is that I am running the mqtt 1.4.8 from the ubuntu xenial PPA on an RPI 2B and I am not using an authenticated connection.  I have the SensorMqtt plugin running on both 1.7.2138 on V+ and 1.5.622 on V3.

I am traveling so it is a bit difficult for me to gin up a configuration similar to yours so I have published a new version for you to test that now provides a last will and testament message in the connection request.  Without the mosquito server logs, it is hard for me to know why the connection isn't staying up (seems like the broker isn't sending a CONNACK for some reason).  Please install the latest version and see if it resolves the issue (you only need to update the L_SensorMqtt1.lua file).

If this change does not resolve the problem, it would be very helpful if you could enable debug logging on the mosquitto broker and provide the logs from both the Vera (verbose and grep provided above to include debug info).  To enable logging on your RPI2, change /etc/mosquitto/mosquitto.conf to include log_type all:

Code: [Select]
log_dest file /var/log/mosquitto/mosquitto.log
log_type all

Then either kill -HUP the mosquitto process or use
Code: [Select]
sudo systemctl restart mosquitto so the broker will load the new config file.  Then tail -f /var/log/mosquitto/mosquitto.log on your RPI2 and restart the luup engine to reload the SensorMqtt plugin so it goes through the connection process.  Finally, trigger one of your watched variables so that the client initiates a reconnect and publish.

Hopefully this will provide all the necessary detail so we can see what is going on from the broker perspective.  Again, maybe you won't need to go through these additional steps with the revised plugin but if it doesn't work, we will need these additional details to triage further and remedy.

Thanks again for your testing...
Title: Re: MQTT Client Plugin
Post by: blacey on September 06, 2016, 09:26:41 am
Mosquitto version 1.4.10 on Raspberry Pi 2B

I just thought of something else...  Are you using
Code: [Select]
clientid_prefixes prefix in your mosquito.conf?  If so, I changed the connection request in the large robustness refactoring to include the serial number for the Vera so it is unique to each controller.  The Vera will now pass 'Vera-(SerialNumber)' in the connection request - for example, Vera-3000299.  I will change the connection log to include the ClientId that the Vera is using to establish the connection but if your broker is configured with a prefix that doesn't match the current SensorMqtt client, then it would reject the connection request.  Perhaps you can also provide your mosquitto configuration file(s) here?
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 06, 2016, 10:45:51 am
I updated to the latest version.
Debug logging will be enabled later on on Mosquitto

Below my mosquitto.conf
Code: [Select]
pid_file /var/run/mosquitto.pid
allow_zero_length_clientid false
persistent_client_expiration 7d
allow_duplicate_messages false
port 1883
listener 8883
cafile /etc/mosquitto/ca.crt
capath /etc/mosquitto/
certfile /etc/mosquitto/pki.crt
keyfile /etc/mosquitto/pki.key
tls_version tlsv1
require_certificate false
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
connection_messages true
log_timestamp true
allow_anonymous false
password_file /etc/mosquitto/passwd
include_dir /etc/mosquitto/conf.d
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 06, 2016, 10:57:12 am
With the newest version of the plugin (reloaded LUUP + rebooted):
Mosquitto log gives:
Code: [Select]
1473173330: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1473173330: Config loaded from /etc/mosquitto/mosquitto.conf.
1473173330: Opening ipv4 listen socket on port 8883.
1473173330: Opening ipv6 listen socket on port 8883.
1473173330: Warning: Address family not supported by protocol
1473173330: Opening ipv4 listen socket on port 1883.
1473173330: Opening ipv6 listen socket on port 1883.
1473173330: Warning: Address family not supported by protocol
1473173340: New connection from 192.168.1.40 on port 1883.
1473173340: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473173340: Sending CONNACK to openhab (0, 0)
1473173340: Received SUBSCRIBE from openhab
1473173340: owntracks/s7/event (QoS 0)
1473173340: openhab 0 owntracks/s7/event
1473173340: Sending SUBACK to openhab
1473173340: Received SUBSCRIBE from openhab
1473173340: /openHAB/in/+/state (QoS 0)
1473173340: openhab 0 /openHAB/in/+/state
1473173340: Sending SUBACK to openhab
1473173387: New connection from 192.168.1.251 on port 1883.
root@rpi2server:/etc/mosquitto# cat /var/log/mosquitto/mosquitto.log
1473173277: Socket error on client <unknown>, disconnecting.
1473173329: Error in poll: Interrupted system call.
1473173329: mosquitto version 1.4.10 terminating
1473173330: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1473173330: Config loaded from /etc/mosquitto/mosquitto.conf.
1473173330: Opening ipv4 listen socket on port 8883.
1473173330: Opening ipv6 listen socket on port 8883.
1473173330: Warning: Address family not supported by protocol
1473173330: Opening ipv4 listen socket on port 1883.
1473173330: Opening ipv6 listen socket on port 1883.
1473173330: Warning: Address family not supported by protocol
1473173340: New connection from 192.168.1.40 on port 1883.
1473173340: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473173340: Sending CONNACK to openhab (0, 0)
1473173340: Received SUBSCRIBE from openhab
1473173340: owntracks/s7/event (QoS 0)
1473173340: openhab 0 owntracks/s7/event
1473173340: Sending SUBACK to openhab
1473173340: Received SUBSCRIBE from openhab
1473173340: /openHAB/in/+/state (QoS 0)
1473173340: openhab 0 /openHAB/in/+/state
1473173340: Sending SUBACK to openhab
1473173387: New connection from 192.168.1.251 on port 1883.
1473173387: Sending CONNACK to 192.168.1.251 (0, 5)
1473173387: Socket error on client <unknown>, disconnecting.
1473173400: Received PUBLISH from openhab (d0, q0, r0, m0, '/openHAB/persist/feed', ... (17 bytes))
root@rpi2server:/etc/mosquitto# cat /var/log/mosquitto/mosquitto.log
1473173277: Socket error on client <unknown>, disconnecting.
1473173329: Error in poll: Interrupted system call.
1473173329: mosquitto version 1.4.10 terminating
1473173330: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1473173330: Config loaded from /etc/mosquitto/mosquitto.conf.
1473173330: Opening ipv4 listen socket on port 8883.
1473173330: Opening ipv6 listen socket on port 8883.
1473173330: Warning: Address family not supported by protocol
1473173330: Opening ipv4 listen socket on port 1883.
1473173330: Opening ipv6 listen socket on port 1883.
1473173330: Warning: Address family not supported by protocol
1473173340: New connection from 192.168.1.40 on port 1883.
1473173340: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473173340: Sending CONNACK to openhab (0, 0)
1473173340: Received SUBSCRIBE from openhab
1473173340: owntracks/s7/event (QoS 0)
1473173340: openhab 0 owntracks/s7/event
1473173340: Sending SUBACK to openhab
1473173340: Received SUBSCRIBE from openhab
1473173340: /openHAB/in/+/state (QoS 0)
1473173340: openhab 0 /openHAB/in/+/state
1473173340: Sending SUBACK to openhab
1473173387: New connection from 192.168.1.251 on port 1883.
1473173387: Sending CONNACK to 192.168.1.251 (0, 5)
1473173387: Socket error on client <unknown>, disconnecting.
1473173400: Received PUBLISH from openhab (d0, q0, r0, m0, '/openHAB/persist/feed', ... (17 bytes))
root@rpi2server:/etc/mosquitto# cat /var/log/mosquitto/mosquitto.log
1473173277: Socket error on client <unknown>, disconnecting.
1473173329: Error in poll: Interrupted system call.
1473173329: mosquitto version 1.4.10 terminating
1473173330: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1473173330: Config loaded from /etc/mosquitto/mosquitto.conf.
1473173330: Opening ipv4 listen socket on port 8883.
1473173330: Opening ipv6 listen socket on port 8883.
1473173330: Warning: Address family not supported by protocol
1473173330: Opening ipv4 listen socket on port 1883.
1473173330: Opening ipv6 listen socket on port 1883.
1473173330: Warning: Address family not supported by protocol
1473173340: New connection from 192.168.1.40 on port 1883.
1473173340: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473173340: Sending CONNACK to openhab (0, 0)
1473173340: Received SUBSCRIBE from openhab
1473173340: owntracks/s7/event (QoS 0)
1473173340: openhab 0 owntracks/s7/event
1473173340: Sending SUBACK to openhab
1473173340: Received SUBSCRIBE from openhab
1473173340: /openHAB/in/+/state (QoS 0)
1473173340: openhab 0 /openHAB/in/+/state
1473173340: Sending SUBACK to openhab
1473173387: New connection from 192.168.1.251 on port 1883.
1473173387: Sending CONNACK to 192.168.1.251 (0, 5)
1473173387: Socket error on client <unknown>, disconnecting.
1473173400: Received PUBLISH from openhab (d0, q0, r0, m0, '/openHAB/persist/feed', ... (17 bytes))
root@rpi2server:/etc/mosquitto# tail -f /var/log/mosquitto/mosquitto.log
1473173340: openhab 0 owntracks/s7/event
1473173340: Sending SUBACK to openhab
1473173340: Received SUBSCRIBE from openhab
1473173340: /openHAB/in/+/state (QoS 0)
1473173340: openhab 0 /openHAB/in/+/state
1473173340: Sending SUBACK to openhab
1473173387: New connection from 192.168.1.251 on port 1883.
1473173387: Sending CONNACK to 192.168.1.251 (0, 5)
1473173387: Socket error on client <unknown>, disconnecting.

vera log
Code: [Select]
cat /tmp/log/cmh/LuaUPnP.log | grep '\(^01\|^02\|^35\|^50\).*SensorMqtt'
35 09/06/16 16:52:55.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:00.104 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:05.118 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:10.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:15.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:20.111 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:25.116 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:30.104 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
35 09/06/16 16:53:35.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x32f73680>
Title: Re: MQTT Client Plugin
Post by: blacey on September 06, 2016, 11:23:50 am
So I can deduce what is happening, what is the IP address of the broker on your RPI and the IP address of your Vera?  An earlier log showed MQTT client configured to connect to 192.168.1.40

Code: [Select]
50 09/06/16 8:52:37.187 luup_log:188: SensorMqtt: Initializing SensorMqtt <0x2b9d3680>
50 09/06/16 8:52:37.230 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x2b9d3680>
50 09/06/16 8:52:37.233 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x2b9d3680>
50 09/06/16 8:52:37.235 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2b9d3680>
50 09/06/16 8:52:37.312 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x2b9d3680>

But your RPI broker log shows that IP address is used by your openhab node. 
Code: [Select]
1473173340: New connection from 192.168.1.40 on port 1883.
1473173340: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473173340: Sending CONNACK to openhab (0, 0)
1473173340: Received SUBSCRIBE from openhab
1473173340: owntracks/s7/event (QoS 0)

Are you running your broker on the same IP 192.168.1.140 as OpenHab or is your broker on a different IP?

Also, it looks like Vera is on 192.168.1.251?  Am I correct in deducing that?

Also, if you haven't, please enable the debug logging on your broker by adding the two lines I posted earlier to your mosquitto.conf file (I didn't see them in what you provided but the output looks like it was enabled).  Here is what I see on my broker with log_type all enabled.

Code: [Select]
1473174909: mosquitto version 1.4.8 terminating
1473174910: mosquitto version 1.4.8 (build date Fri, 19 Feb 2016 12:03:16 +0100) starting
1473174910: Config loaded from /etc/mosquitto/mosquitto.conf.
1473174910: Opening ipv4 listen socket on port 1883.
1473174910: Opening ipv6 listen socket on port 1883.
1473174910: Bridge local.brookside doing local SUBSCRIBE on topic Vera/#
1473174910: Connecting bridge brookside-to-mqtt (mqtt.blacey.com:8883)
1473174910: Bridge brookside sending CONNECT
1473174910: Received CONNACK on connection local.brookside.
1473174910: Bridge local.brookside sending UNSUBSCRIBE (Mid: 95, Topic: Vera/#)
1473174910: Received PUBACK from local.brookside (Mid: 94)
1473174910: Received UNSUBACK from local.brookside
1473174923: New connection from 10.0.1.225 on port 1883.
1473174923: New client connected from 10.0.1.225 as Vera-30002905 (c1, k60).
1473174923: Sending CONNACK to Vera-30002905 (0, 0)
1473174923: Received PUBLISH from Vera-30002905 (d0, q0, r0, m0, 'Vera/30002905/SwitchPower1/19', ... (255 bytes))
1473174923: Sending PUBLISH to local.brookside (d0, q0, r0, m0, 'Vera/30002905/SwitchPower1/19', ... (255 bytes))
1473174923: Received PUBLISH from Vera-30002905 (d0, q0, r0, m0, 'Vera/30002905/EnergyMetering1/19', ... (262 bytes))
1473174923: Sending PUBLISH to local.brookside (d0, q0, r0, m0, 'Vera/30002905/EnergyMetering1/19', ... (262 bytes))
1473174992: Received PINGREQ from Vera-30002905
1473174992: Sending PINGRESP to Vera-30002905

Finally, during your test, please poke your Vera to publishing a message by tripping or changing one of the watched variables - that will cause the Vera to try to connect again (perhaps you did in your last test?)

Stefan, I would also like to confirm that we are working with the same version of the dependencies.  Please compute the md5 checksums as follows:

Code: [Select]
root@MiOS_30002905:~# openssl dgst -md5 /usr/lib/lua/mqtt_library.lua
MD5(/usr/lib/lua/mqtt_library.lua)= d277c620e1d55b6981c905d0a336216f
root@MiOS_30002905:~# openssl dgst -md5 /usr/lib/lua/utility.lua
MD5(/usr/lib/lua/utility.lua)= 178cf5910a31768703efecf744691700

All of that said, I plan to make some changes but they won't change these results here:


Looking forward to your reply with additional details!
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 07, 2016, 02:43:02 am
My openhab 1.8.3 is running on 192.168.1.40
Mosquitto is also running on 192.168.1.40
Vera is 192.168.1.251

log_type all is set in mosquitto.
Code: [Select]
pid_file /var/run/mosquitto.pid
allow_zero_length_clientid false
persistent_client_expiration 7d
allow_duplicate_messages false
port 1883
listener 8883
cafile /etc/mosquitto/ca.crt
capath /etc/mosquitto/
certfile /etc/mosquitto/pki.crt
keyfile /etc/mosquitto/pki.key
tls_version tlsv1
require_certificate false
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
log_type all
connection_messages true
log_timestamp true
allow_anonymous false
password_file /etc/mosquitto/passwd
include_dir /etc/mosquitto/conf.d

Below my logs
Mosquitto
Code: [Select]
1473230930: Sending PINGRESP to openhab
1473230983: Error in poll: Interrupted system call.
1473230983: mosquitto version 1.4.10 terminating
1473230983: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1473230983: Config loaded from /etc/mosquitto/mosquitto.conf.
1473230983: Opening ipv4 listen socket on port 8883.
1473230983: Opening ipv6 listen socket on port 8883.
1473230983: Warning: Address family not supported by protocol
1473230983: Opening ipv4 listen socket on port 1883.
1473230983: Opening ipv6 listen socket on port 1883.
1473230983: Warning: Address family not supported by protocol
1473231011: New connection from 192.168.1.251 on port 1883.
1473231011: Sending CONNACK to 192.168.1.251 (0, 5)
1473231011: Socket error on client <unknown>, disconnecting.
1473231018: New connection from 192.168.1.40 on port 1883.
1473231018: New client connected from 192.168.1.40 as openhab (c1, k60, u'openhab').
1473231018: Sending CONNACK to openhab (0, 0)
1473231031: New connection from 192.168.1.251 on port 1883.
1473231031: Sending CONNACK to 192.168.1.251 (0, 5)
1473231031: Socket error on client <unknown>, disconnecting.
1473231031: New connection from 192.168.1.251 on port 1883.
1473231031: Sending CONNACK to 192.168.1.251 (0, 5)
1473231031: Socket error on client <unknown>, disconnecting.
1473231031: New connection from 192.168.1.251 on port 1883.
1473231031: Sending CONNACK to 192.168.1.251 (0, 5)
1473231031: Socket error on client <unknown>, disconnecting.
1473231031: New connection from 192.168.1.251 on port 1883.
1473231031: Sending CONNACK to 192.168.1.251 (0, 5)
1473231031: Socket error on client <unknown>, disconnecting.
1473231032: New connection from 192.168.1.251 on port 1883.
1473231032: Sending CONNACK to 192.168.1.251 (0, 5)
1473231032: Socket error on client <unknown>, disconnecting.
1473231048: Received SUBSCRIBE from openhab
1473231048: owntracks/s7/event (QoS 0)
1473231048: openhab 0 owntracks/s7/event
1473231048: Sending SUBACK to openhab
1473231050: Received SUBSCRIBE from openhab

vera
Code: [Select]
50 09/07/16 8:50:11.700 luup_log:188: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x2c2eb680>
50 09/07/16 8:50:11.842 luup_log:188: SensorMqtt: Plugin module L_SensorMqtt1 loaded <0x2c2eb680>
50 09/07/16 8:50:11.842 luup_log:188: SensorMqtt: Initializing SensorMqtt <0x2c2eb680>
50 09/07/16 8:50:11.868 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x2c2eb680>
35 09/07/16 8:50:11.869 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x2c2eb680>
50 09/07/16 8:50:11.872 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x2c2eb680>
50 09/07/16 8:50:11.873 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2c2eb680>
35 09/07/16 8:50:11.898 luup_log:188: SensorMqtt: ************************************************ MQTT Settings ************************************************ <0x2c2eb680>
35 09/07/16 8:50:11.899 luup_log:188: SensorMqtt: Watching urn:akbooer-com:serviceId:Netatmo1 on variable LastUpdated with label LastUpdated <0x2c2eb680>
35 09/07/16 8:50:11.906 luup_log:188: SensorMqtt: Watching urn:akbooer-com:serviceId:Netatmo1 on variable Timestamp with label Timestamp <0x2c2eb680>
35 09/07/16 8:50:11.913 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventTime with label LastLogEventTime <0x2c2eb680>
35 09/07/16 8:50:11.921 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventUser with label LastLogEventUser <0x2c2eb680>
35 09/07/16 8:50:11.928 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEvent with label LastLogEvent <0x2c2eb680>
35 09/07/16 8:50:11.936 luup_log:188: SensorMqtt: Watching urn:futzle-com:serviceId:CaddxNX584Security1 on variable LastLogEventPartition with label LastLogEventPartition <0x2c2eb680>
35 09/07/16 8:50:11.943 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status3 with label Status3 <0x2c2eb680>
35 09/07/16 8:50:11.945 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status1 with label Status1 <0x2c2eb680>
35 09/07/16 8:50:11.947 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status4 with label Status4 <0x2c2eb680>
35 09/07/16 8:50:11.948 luup_log:188: SensorMqtt: Watching urn:dcineco-com:serviceId:MSwitch1 on variable Status2 with label Status2 <0x2c2eb680>
35 09/07/16 8:50:11.950 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:HouseModes1 on variable HMode with label HMode <0x2c2eb680>
35 09/07/16 8:50:11.951 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:HouseModes1 on variable Message with label Message <0x2c2eb680>
35 09/07/16 8:50:11.953 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable ArmedTripped with label ArmedTripped <0x2c2eb680>
35 09/07/16 8:50:11.960 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Tripped with label Tripped <0x2c2eb680>
35 09/07/16 8:50:11.968 luup_log:188: SensorMqtt: Watching urn:micasaverde-com:serviceId:SecuritySensor1 on variable Armed with label Armed <0x2c2eb680>
35 09/07/16 8:50:11.976 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x2c2eb680>
50 09/07/16 8:50:11.977 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x2c2eb680>
35 09/07/16 8:50:16.119 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:21.105 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:26.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:31.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:31.488 luup_log:188: SensorMqtt: Watch event - device: 151 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.502 luup_log:188: SensorMqtt: Sending [Living - Humidity] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.503 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":151,"DeviceName":"Living - Humidity","DeviceType":"urn:schemas-micasaverde-com:device:HumiditySensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.503 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:31.504 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:31.507 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:31.508 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:31.591 luup_log:188: SensorMqtt: Watch event - device: 152 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.594 luup_log:188: SensorMqtt: Sending [Living - Temperature] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.595 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":152,"DeviceName":"Living - Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
02 09/07/16 8:50:31.596 luup_log:188: SensorMqtt: Unable to publish, connection down.  Discarding message: {"DeviceId":152,"DeviceName":"Living - Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.597 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x32ceb680>
35 09/07/16 8:50:31.696 luup_log:188: SensorMqtt: Watch event - device: 153 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.699 luup_log:188: SensorMqtt: Sending [Living - Pressure] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.700 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":153,"DeviceName":"Living - Pressure","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.701 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:31.701 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:31.705 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:31.706 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:31.771 luup_log:188: SensorMqtt: Watch event - device: 177 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.774 luup_log:188: SensorMqtt: Sending [Living - Noise] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.774 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":177,"DeviceName":"Living - Noise","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
02 09/07/16 8:50:31.776 luup_log:188: SensorMqtt: Unable to publish, connection down.  Discarding message: {"DeviceId":177,"DeviceName":"Living - Noise","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.777 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x32ceb680>
35 09/07/16 8:50:31.832 luup_log:188: SensorMqtt: Watch event - device: 178 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.835 luup_log:188: SensorMqtt: Sending [Living - CO2] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.836 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":178,"DeviceName":"Living - CO2","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.837 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:31.837 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:31.840 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:31.841 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:31.902 luup_log:188: SensorMqtt: Watch event - device: 156 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.905 luup_log:188: SensorMqtt: Sending [regenmeter - Rain] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.906 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":156,"DeviceName":"regenmeter - Rain","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
02 09/07/16 8:50:31.907 luup_log:188: SensorMqtt: Unable to publish, connection down.  Discarding message: {"DeviceId":156,"DeviceName":"regenmeter - Rain","DeviceType":"urn:akbooer-com:device:NetatmoMetric:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.908 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x32ceb680>
35 09/07/16 8:50:31.939 luup_log:188: SensorMqtt: Watch event - device: 157 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:31.943 luup_log:188: SensorMqtt: Sending [Tuin - Humidity] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:31.944 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":157,"DeviceName":"Tuin - Humidity","DeviceType":"urn:schemas-micasaverde-com:device:HumiditySensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:31.944 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:31.945 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:31.948 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:31.949 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:31.992 luup_log:188: SensorMqtt: Watch event - device: 158 variable: LastUpdated value 1473230501 => 1473231031 <0x32ceb680>
50 09/07/16 8:50:32.002 luup_log:188: SensorMqtt: Sending [Tuin - Temperature] LastUpdated changed to 1473231031 from 1473230501 on topic {} <0x32ceb680>
35 09/07/16 8:50:32.003 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":158,"DeviceName":"Tuin - Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
02 09/07/16 8:50:32.005 luup_log:188: SensorMqtt: Unable to publish, connection down.  Discarding message: {"DeviceId":158,"DeviceName":"Tuin - Temperature","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","LastUpdated":1473231031,"OldLastUpdated":1473230501,"RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231031,"Variable":"LastUpdated"} <0x32ceb680>
50 09/07/16 8:50:32.006 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x32ceb680>
35 09/07/16 8:50:32.127 luup_log:188: SensorMqtt: Watch event - device: 150 variable: Timestamp value Wed 08:41 => Wed 08:50 <0x32ceb680>
50 09/07/16 8:50:32.131 luup_log:188: SensorMqtt: Sending [Netatmo] Timestamp changed to Wed 08:50 from Wed 08:41 on topic {} <0x32ceb680>
35 09/07/16 8:50:32.131 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":150,"DeviceName":"Netatmo","DeviceType":"urn:akbooer-com:device:Netatmo:1","OldTimestamp":"Wed 08:41","RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231032,"Timestamp":"Wed 08:50","Variable":"Timestamp"} <0x32ceb680>
50 09/07/16 8:50:32.132 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:32.133 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:32.136 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:32.137 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:36.125 luup_log:188: SensorMqtt: Connection down: socket_client:receive(): closed <0x332eb680>
50 09/07/16 8:50:36.126 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x332eb680>
35 09/07/16 8:50:41.106 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:46.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:51.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:50:56.105 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:01.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:06.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:11.116 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:16.108 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:21.129 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:26.105 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>
35 09/07/16 8:51:31.115 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x332eb680>

checksums (just reuploaded latest download from github page)
Code: [Select]
MD5(/usr/lib/lua/mqtt_library.lua)= d277c620e1d55b6981c905d0a336216f
MD5(/usr/lib/lua/utility.lua)= 9bb0529b5a3d4368376a37ba9453dc4f
Title: Re: MQTT Client Plugin
Post by: blacey on September 07, 2016, 08:35:08 am

My openhab 1.8.3 is running on 192.168.1.40
Mosquitto is also running on 192.168.1.40
Vera is 192.168.1.251

Below my logs
Mosquitto
Code: [Select]
1473231011: New connection from 192.168.1.251 on port 1883.
1473231011: Sending CONNACK to 192.168.1.251 (0, 5)
1473231011: Socket error on client <unknown>, disconnecting.

vera
Code: [Select]
50 09/07/16 8:50:11.868 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x2c2eb680>
35 09/07/16 8:50:11.869 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x2c2eb680>
50 09/07/16 8:50:11.872 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x2c2eb680>
50 09/07/16 8:50:11.873 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2c2eb680>
35 09/07/16 8:50:11.976 luup_log:188: SensorMqtt: Connection down: /usr/lib/lua/mqtt_library.lua:382: MQTT.client:handler(): Not connected <0x2c2eb680>
50 09/07/16 8:50:11.977 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x2c2eb680>

35 09/07/16 8:50:32.127 luup_log:188: SensorMqtt: Watch event - device: 150 variable: Timestamp value Wed 08:41 => Wed 08:50 <0x32ceb680>
50 09/07/16 8:50:32.131 luup_log:188: SensorMqtt: Sending [Netatmo] Timestamp changed to Wed 08:50 from Wed 08:41 on topic {} <0x32ceb680>
35 09/07/16 8:50:32.131 luup_log:188: SensorMqtt: Publish topic: {} message:{"DeviceId":150,"DeviceName":"Netatmo","DeviceType":"urn:akbooer-com:device:Netatmo:1","OldTimestamp":"Wed 08:41","RoomId":9,"RoomName":"3-Netatmo","ServiceId":"urn:akbooer-com:serviceId:Netatmo1","Time":1473231032,"Timestamp":"Wed 08:50","Variable":"Timestamp"} <0x32ceb680>
50 09/07/16 8:50:32.132 luup_log:188: SensorMqtt: Connecting to MQTT, mqttServerIp: 192.168.1.40 mqttServerPort: 1883... <0x32ceb680>
35 09/07/16 8:50:32.133 luup_log:188: SensorMqtt: Authenticating with username: openhab <0x32ceb680>
50 09/07/16 8:50:32.136 luup_log:188: SensorMqtt: Successfully connected to broker: 192.168.1.40 on port 1883 <0x32ceb680>
50 09/07/16 8:50:32.137 luup_log:188: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x32ceb680>
35 09/07/16 8:50:36.125 luup_log:188: SensorMqtt: Connection down: socket_client:receive(): closed <0x332eb680>
50 09/07/16 8:50:36.126 luup_log:188: SensorMqtt: MQTT connection status changed from "Connected" to "Disconnected" <0x332eb680>

checksums (just reuploaded latest download from github page)
Code: [Select]
MD5(/usr/lib/lua/mqtt_library.lua)= d277c620e1d55b6981c905d0a336216f
MD5(/usr/lib/lua/utility.lua)= 9bb0529b5a3d4368376a37ba9453dc4f

After seeing this, I went back and scrubbed/inspected each and every client authentication step and found a typo in the variable name for the mqtt broker password!  I have fixed that typo, added the mqtt client id to the info logging and committed the changes to git.

Please try the latest version of the plugin on GitHub including the dependency utility.lua (I didn't update it but your checksum doesn't match the GitHub checksum so perhaps you missed this one when I upgraded SensorMqtt to use the Paho 0.3 mqtt lua client.  Here are the checksums for everything.

Code: [Select]
$ find . -type f -not -path './.git/*' -exec openssl dgst -md5 {} \;
MD5(./Dependencies/usr/lib/lua/JSON.lua)= 7df77af31f3854a8db9dc82fcf789dea
MD5(./Dependencies/usr/lib/lua/mqtt_library.lua)= d277c620e1d55b6981c905d0a336216f
MD5(./Dependencies/usr/lib/lua/utility.lua)= 70673ff99bbc4015803facd6fe6687b5
MD5(./Plugin/D_SensorMqtt1.json)= c7d8b12e2e5fe2d61edfd614b815f9e1
MD5(./Plugin/D_SensorMqtt1.xml)= 4326276bc240949c9914fb8bb1043c6b
MD5(./Plugin/I_SensorMqtt1.xml)= 3ff8c0074b14a9908586d70c3e507fc1
MD5(./Plugin/J_SensorMqtt1.js)= 5d63ee1c3e28221be85dea901c4a0993
MD5(./Plugin/L_SensorMqtt1.lua)= 9dce0494565d602abf15a89110aa27f5
MD5(./Plugin/S_SensorMqtt1.xml)= 23bc8fa230b8be8c29b130d6f9ce95c0
[code]

I really, really appreciate your patience in running numerous tests.  Had I not been traveling, I would have set up an authenticated broker instance running 1.4.10 to mimic your config and dug in to find this on my own.  I'm pretty sure we nailed it though and thanks again for all your help and patience!
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 07, 2016, 09:10:36 am
Hi Blacey, guess what...

Code: [Select]
MQTT IP: 192.168.1.40
MQTT Port: 1883
MQTT User: openhab
MQTT Status: Connected
MQTT Last Message:
{"Payload":"{\"DeviceId\":150,\"DeviceName\":\"Netatmo\",\"DeviceType\":\"urn:akbooer-com:device:Netatmo:1\",\"OldTimestamp\":\"Wed 15:00\",\"RoomId\":9,\"RoomName\":\"3-Netatmo\",\"ServiceId\":\"urn:akbooer-com:serviceId:Netatmo1\",\"Time\":1473253666,\"Timestamp\":\"Wed 15:07\",\"Variable\":\"Timestamp\"}","Topic":"{}"}

I think the problem has been solved. Connection is established!
Thanks a lot for your support and quick response!
I'm looking forward to further developments of your plugin and I'm certainly willing to test if it can help you.

Subscribing to mqtt broker for reading values can be a great update since this could open the door to owntracks integration.
Title: Re: MQTT Client Plugin
Post by: blacey on September 07, 2016, 09:51:47 am
I think the problem has been solved. Connection is established!
Thanks a lot for your support and quick response!
I'm looking forward to further developments of your plugin and I'm certainly willing to test if it can help you.

Subscribing to mqtt broker for reading values can be a great update since this could open the door to owntracks integration.

Awesome!   :) :) :)  Thanks for your diligent and methodical testing and feedback.

Feel free to outline the owntracks use case that you envision to influence the direction of the plugin. ;)
Title: Re: MQTT Client Plugin
Post by: stefaanbolle on September 07, 2016, 10:24:52 am
Owntracks reports it's status/presence on Android/iOS using mqtt to a mqtt broker.
It would be great if a plugin in Vera would allow to use owntracks as presence tracker (kind of iphone locator plugin) and additionally shows any monitored device (ie kids) on a map in vera.
That's in short my usecase.
Title: Re: MQTT Client Plugin
Post by: kodarn on November 02, 2016, 06:45:25 pm
Interesting Work! :D

Would it be possible to share the Node-Red flow?
Title: Re: MQTT Client Plugin
Post by: kodarn on November 05, 2016, 05:18:25 am
I got the plugin working. I documented the steps below. This guide assumes you have installed a MQTT-broker on a remote Raspberry Pi. The MQTT-Broker I'm using is Mosquitto. Check out https://www.youtube.com/watch?v=AsDHEDbyLfg for instructions on how to install it.

Code: [Select]
#1 Download the zip from https://github.com/jonferreira/vera-mqtt to my MacBook

#2 Copy the Dependency-files to the Vera
#2.1 Terminal
#2.2 cd ~/Downloads/
#2.3 scp vera-mqtt-master.zip root@vera:
#2.4 ssh root@vera
#2.5 unzip vera-mqtt-master.zip
#2.6 cp vera-mqtt-master/Dependencies/usr/lib/lua/* /usr/lib/lua/

#3 Copy the Plugin-files to the Vera
#3.1 Terminal
#2.2 cd ~/Downloads/
#3.1.2 unzip vera-mqtt-master.zip
#3.2 Start up your FireFox-browser
#3.2.1 http://vera/cmh/#develop_apps
#3.2.2 Luup files -> Upload
#3.2.3 Select all files in the unpacked vera-mqtt-master/Plugin directory

#4 Create a new Device using the newly uploaded Plugin-files
     http://vera/cmh/#develop_apps -> Create device ->
     Description                  = "MQTT client"
     Upnp Device FileName         = "D_SensorMqtt1.xml"
     Upnp Implementation Filename = "I_SensorMqtt1.xml"
     -> Create device

#5 Reload luup
     http://vera:3480/data_request?id=reload

#6 Wait a few moments, and the newly created device will popup at http://vera/cmh/#devices
   However, the device fails with the error messsage "MQTT client[189]: Startup Lua Failed"
   Okey, so we need to peek in the logs on the Vera

     ssh root@vera
     cat /tmp/log/cmh/LuaUPnP.log | grep '\(^01\|^02\|^35\|^50\).*SensorMqtt'

   Doh! Reading the error message you now realize that you need to configure the plugin :-P

#7 http://vera/cmh/#devices -> MQTT client -> Advanced -> Variables tab
     mqttServerIp        = Raspberry_ip
     mqttServerPort      = 1883
     mqttServerUser      = username
     mqttServerPassword  = password

#8 Start a subscriber on the Raspberry, and verify the credentials you have provided above
       mosquitto_sub -h 127.0.0.1 -p 1883 -u username -P password -t Vera/#
       mosquitto_pub -h 127.0.0.1 -p 1883 -u username -P password -t Vera/Event/DeviceAlias -m "qwerty"

#9 Start pushing event changes from Vera-attached devices

     http://vera/cmh/#devices -> MQTT client -> WatchDog -> and checkbox the following
       * urn:upnp-org:serviceId:TemperatureSensor1     CurrentTemperature  CurrentTemperature
       * urn:micasaverde-com:serviceId:HumiditySensor1 CurrentLevel        CurrentLevel
       * urn:upnp-org:serviceId:SwitchPower1           Status              Status
       -> Save Changes

#10 Reload luup
     http://vera:3480/data_request?id=reload

#11 Go into the Vera-gui and toggle a lightswitch
     http://vera/cmh/#devices

#12 Go back to the scrubscriber that you started at step #8. You should now see the mqtt-message there.
Title: Re: MQTT Client Plugin
Post by: kodarn on November 05, 2016, 05:36:38 am
I got the Node-Red thing working on my Raspberry Pi 3 (RPI3). This guide assumes you have previously set up the MQTT-Broker 'Mosquitto' on the RPI3. Here's how I did it:

Code: [Select]
#--------------------------------
# 1. Install InfluxDb on the RPI3
#--------------------------------
ssh pi@raspberry_ip

  sudo apt-get install apt-transport-https
  curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add - source /etc/os-release
  echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
  sudo apt-get update && sudo apt-get install influxdb
  sudo systemctl start influxdb

  -> InfluxDb Admin gui             = http://raspberry_ip:8083/
  -> InfluxDb data get/set via http = http://raspberry_ip:8086/

#----------------------
# 2. Configure InfluxDb
#----------------------
influx
  CREATE DATABASE "vera_db"
  SHOW DATABASES

  CREATE USER "nodered" WITH PASSWORD 'nodered'
  GRANT WRITE ON vera_db TO nodered

  CREATE USER "grafana" WITH PASSWORD 'grafana'
  GRANT READ ON vera_db TO grafana

  SHOW USERS
  SHOW GRANTS FOR nodered
  SHOW GRANTS FOR grafana

#------------------------------------------------------------------------
# 3. Install Node Red on the RPI3
#    (Check out http://nodered.org/docs/hardware/raspberrypi for details)
#------------------------------------------------------------------------
ssh pi@raspberry_ip
  sudo apt-get update
  sudo apt-get install nodered
  sudo apt-get install npm
  sudo npm install -g npm@2.x
  sudo apt-get install sense-hat

  sudo systemctl enable nodered.service
  sudo node-red-start

    -> NodeRed web gui = http://raspberry_ip:1880

#---------------------------------
# 4. Create the 'flow' in Node-Red
#---------------------------------

# 4.1 - Drag/Drop an MQTT-inputnode and configure it:
  Server   = 127.0.0.1:1883
  Topic    = Vera/#
  QoS      = 2
  Name     = MQTT input on topic Vera/#

# 4.2 - Drag/Drop a Function-Node and configure it:
  Name     = Function converting MQTT msg to InfluxDB-format
  Outputs  = 1
  Function =
             //------------------------------------------------------------
             // 1. Retrieve incoming values from the Mosquitto-MQTT message
             //------------------------------------------------------------
             var Topic = msg.topic;
             
             var Influx_Key    = "Unknown_key";
             var Inflex_KeyTag = "Unknown_tag";
             var Influx_Value  = "Unknown_value";
             
             var objJson = JSON.parse(msg.payload);
             var DeviceName         = objJson.DeviceName;
             var DeviceType         = objJson.DeviceType;
             var Variable           = objJson.Variable;
             var DeviceId           = objJson.DeviceId;
             var RoomName           = objJson.RoomName;
             var Time               = objJson.Time;
             
             //
             // Replace any spaces with underscore characters in DeviceNames
             //
             DeviceName=DeviceName.replace(/ /g,"_");
             
             //
             // We have different value-variables depending on the DeviceType that sent the msg
             // You need to extend this section for other sensors
             //
             if (DeviceType.indexOf("HumiditySensor") !=-1)
             {
                 Influx_Key    = "humidity";
                 Influx_KeyTag = "device=" + DeviceName;
                 Influx_Value  = "value="  + objJson.CurrentLevel;
             }
             if (DeviceType.indexOf("TemperatureSensor") !=-1)
             {
                 Influx_Key    = "temperature";
                 Influx_KeyTag = "device=" + DeviceName;
                 Influx_Value  = "value="  + objJson.CurrentTemperature;
             }

             //-----------------------------------------------------------
             // 2. Convert the retrieved data above into an InfluxDb-
             //    compatible format string.
             //
             //    Influx text based line protocol:
             //        [key] [fields] [timestamp]
             //
             //    Example: temperature,device=BedroomTemp value=11.3
             //-----------------------------------------------------------
             var InfluxFmtStr = Influx_Key + ',' + Influx_KeyTag + ' ' + Influx_Value;
             
             //-----------------------------------------------------------
             // 3. Create a new object containing our formatted InfluxDb
             //    string and return it, so it will be passed to the next
             //    component in the Node Red pipeline
             //-----------------------------------------------------------
             var DatabaseName = 'vera_db';
             var newMsg={};
             newMsg.payload = new Buffer(InfluxFmtStr);
             newMsg.url     = "http://127.0.0.1:8086/write?db=" + DatabaseName;
             return newMsg;

# 4.3 - Drag/Drop a http-inputnode and configure it
  Method                             = POST
  URL                                = http://127.0.0.1:8086/write?db=vera_db
  Enable secure (SSL/TLS) connection = No
  Use basic authentication           = No
  Return                             = a UTF-8 string
  Name                               = http input req sending to InfluxDB

# 4.4 - Connect the device chain: MQTT -> Function -> HTTP

# 4.5 - Press the red Deploy-button

#------------------------------------------------------------------------------------
# 5. Test NodeRed-flow by publishing an MQTT message using the commandline tool
#    'mosquitto_pub'. Verify the data is inserted in the InfluxDb database.
#------------------------------------------------------------------------------------
mosquitto_pub -t Vera/test -m '{"CurrentTemperature":11.3,"DeviceId":151,"DeviceName":"BedroomTemp","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","OldCurrentTemperature":11.4,"RoomId":13,"RoomName":"Bedroom","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1478159673,"Variable":"CurrentTemperature"}'

influx
  use vera_db
  show series
  select * from temperature
  select * from temperature where device='BedroomTemp'
Title: Re: MQTT Client Plugin
Post by: kodarn on November 05, 2016, 05:45:30 am
Here's a screendump of my Node-Red flow.
Title: Re: MQTT Client Plugin
Post by: blacey on November 05, 2016, 02:15:55 pm
Interesting Work! :D

Would it be possible to share the Node-Red flow?

Hi @kodarn, it seems like you are making great progress on your MQTT deployment.  In the spirit of sharing, here are a few pertinent details for my deployment and I am happy to provide any additional details that you would like...  I am also using mosquitto to collect sensor measurements from 4 Veras running UI7 at different geographic locations.  Each Vera reports into a local mqtt broker running on an RPI that is bridged to the central broker (SeapSpray) and they communicate using TLS/SSL over the Internet.  The impetus is that the local MQTT broker will cache sensor readings whenever the Internet is down and then reconnect when the Internet is up at which point it will send all previous and current sensor readings/measurements to the central broker virtually eliminating any data loss. 

To simplify the NodeRed transformation, I use the MQTT identifier Vera/(SerialNumber)/(ServiceName)/(DeviceId) so I can persist all measurements (i.e. ServiceNames) to separate InfluxDB named by SerialNumber.  So I have a single measure transform for all incoming measures that are then split out into the respective databases.

I have attached a diagram of my deployment and NodeRed topology and here is the core measure transform:

Code: [Select]
// Transform MQTT payload into InfluxDB measure
// Topic is defined as Vera/(Serial)/(Service)/(DeviceId)
var measure = {};
var payload = new Array(2);

// Set the measurement for this measure (3rd element from topic)
// MQTT Client Topic Publish == Vera/(SerialNumber)/(ServiceName)/(DeviceId)
measure.measurement = msg.topic.split('/')[2];

data = msg.payload;

// Field first, with time converted to milliseconds
valueAsString = data[data.Variable];
if (!isNaN(parseFloat(valueAsString)) && isFinite(valueAsString)) {
    value = parseFloat(valueAsString);
} else {
    value = valueAsString;
}

payload[0] = {
    [data.Variable] : value,
    time            : data.Time + '000'
};

// Tags
payload[1] = {
    deviceId    : data.DeviceId,
    deviceName  : data.DeviceName,
    deviceType  : data.DeviceType.split(':').slice(-2)[0],
};

measure.topic = msg.topic;
measure.payload = payload;

// Update the status with the # of messages processed
var count = context.get('count')||0;
count += 1;
context.set('count', count);

node.status({text: count});

return measure;

Note, my core measure transform is designed to allow replay of external legacy events hence the 'parseFloat()' checks so not needed if you aren't going to replay data and you don't really need to create a new output measure, you can simply modify the input measure.  This is working great for me so I haven't taken the time to simplify further.

Cheers,
Bruce
Title: Re: MQTT Client Plugin
Post by: kodarn on November 05, 2016, 02:56:27 pm
Great work Bruce!

Thanks for sharing  :)
Title: Re: MQTT Client Plugin
Post by: vosmont on December 05, 2016, 05:42:04 pm
Hello ! Great work !
It works well.

As I needed to be able to manage MQTT message from the broker, I've added subscribe action :
https://github.com/vosmont/vera-mqtt

Topic and payload can be retrieved in variables "mqttLastReceivedTopic" and "mqttLastReceivedPayload".
Title: Re: MQTT Client Plugin
Post by: Ispep on December 19, 2016, 05:19:19 pm
 Great work! This plugin made my need for advanced scenes in Vera less important!

This plugin with Node red, influxdb and Grafana has made my home automation system much better and easier to extend features to. 
Currently verifying that my SMS modem works correctly with the node Red flows, when this is verified I have 5000 SMS / month to use with Node Red and Vera!

I made an RPI tutorial that now includes this plugin for Vera :)   
Currently I made:
     Influxdb
     Grafana (v4) 
     Node red
     Mosquitto
     This MQTT plugin
The guide is in Swedish, but google translate works "OK" 

http://www.automatiserar.se/guide-raspberry-pi/ (http://www.automatiserar.se/guide-raspberry-pi/)

Great job on the plugin!

// Ispep
Title: Re: MQTT Client Plugin
Post by: fsa317 on December 21, 2016, 10:56:48 pm
Just came across this thread and it was exactly what I was looking for.  Thanks for the great plug-in.

Two related questions:

1) Should this work if I use a hostname and not an IP address for the message broker?  It isn't for me.
2) If the broker is disconnected, will there be an issues in my general Vera usage if the broker can't be connected to?

Related to #1 I noticed that if I ssh into my vera I can't ping the raspberry pi by hostname but I can by IP, I'm guessing that is the underlying issue.
Title: Re: MQTT Client Plugin
Post by: vosmont on December 23, 2016, 06:12:31 am
Some modifications :
https://github.com/vosmont/vera-mqtt

You can subscribe to a topic by creating a child device :

1/ Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
2/ Reload LUUP engine.
3/ Change the attribut "id_parent" with the id of the MQTT plugin device.
4/ Reload LUUP engine and refresh your browser.
5/ You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
6/ Set the topic you want to subcribe to and the target (format:  service,variable=(formula in LUA)).
7/ Reload LUUP engine.

If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula.

examples :


Topic  : Test/#
Target: urn:upnp-org:serviceId:SwitchPower1,Status=payload.value and ((payload.value=="alarm") and "1" or "0")

On a message from topic 'Test/Something' with payload '{"value":"alarm"}', the switch will be powered on.


Topic  : Test/+/Sensor
Target: urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.temperature and (tonumber(payload.temperature) or "0")

On a message from topic 'Test/Something/Sensor' with payload "{"temperature ":"15.2", "hygrometry":"80"}", the temperature will be set to 15,2.
Title: Re: MQTT Client Plugin
Post by: Tommi on December 31, 2016, 03:15:13 am
You can subscribe to a topic by creating a child device :

1/ Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
2/ Reload LUUP engine.
3/ Change the attribut "id_parent" with the id of the MQTT plugin device.
4/ Reload LUUP engine and refresh your browser.
5/ You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
6/ Set the topic you want to subcribe to and the target (format:  service,variable=(formula in LUA)).
7/ Reload LUUP engine.

If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula.

examples :


Topic  : Test/#
Target: urn:upnp-org:serviceId:SwitchPower1,Status=payload.value and ((payload.value=="alarm") and "1" or "0")

On a message from topic 'Test/Something' with payload '{"value":"alarm"}', the switch will be powered on.


Topic  : Test/+/Sensor
Target: urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.temperature and (tonumber(payload.temperature) or "0")

On a message from topic 'Test/Something/Sensor' with payload "{"temperature ":"15.2", "hygrometry":"80"}", the temperature will be set to 15,2.


I have successfully started MQTT on OpenLuup installation, and sensors are reported to Mosquitto.
however I'm not able to read anything via child devices. 
creating child devices does not create variables which you mention so I use workaround:
Code: [Select]
do -- MQTT
local dev = luup.create_device ('', "System", "System", "D_TemperatureSensor1.xml")
local sid = "urn:schemas-upnp-org:device:TemperatureSensor:1"
luup.variable_set (sid, "CurrentTemperature", "", dev)
luup.variable_set (sid, "mqttTarget", "", dev)
luup.variable_set (sid, "mqttTopic", "", dev)
end
and I have device with two variables (nothing more)
how can I show temperature from MQTT?
message from other client
Code: [Select]
{"CurrentTemperature":28.3,"DeviceId":88,"DeviceName":"Temp.Kaloryfery","DeviceType":"urn:schemas-micasaverde-com:device:TemperatureSensor:1","OldCurrentTemperature":28.4,"RoomId":5,"RoomName":"Kotłownia","ServiceId":"urn:upnp-org:serviceId:TemperatureSensor1","Time":1483171789,"Variable":"CurrentTemperature"}
Could you please help in understanding your example on my specific case?
Title: Re: MQTT Client Plugin
Post by: vosmont on January 05, 2017, 05:57:41 am
Hello Tommi,

I have successfully started MQTT on OpenLuup installation, and sensors are reported to Mosquitto.
however I'm not able to read anything via child devices. 

I think you haven't linked the newly created device to the MQTT plugin.

You can try this :
Code: [Select]
do -- MQTT
   local parentId = 999 -- The id of the device of the MQTT plugin
   local internalId = "System" -- Has to be unique if you create several child devices
   local dev = luup.create_device ('', internalId, "System", "D_TemperatureSensor1.xml", nil, nil, nil, nil, nil, parentId)
end

Reload your Luup engine, refresh your browser and you should see the new variables.

Then you can set these variables :

Topic (e.g.) : Vera/+/TemperatureSensor1/88
Target: urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.CurrentTemperature and (tonumber(payload.CurrentTemperature) or "0")
Title: Re: MQTT Client Plugin
Post by: castrov on January 12, 2017, 10:36:07 pm
I've installed this using the great instructions provided but it is failing... anyone have any idea what this means:

01   01/12/17 22:33:26.347   LuaInterface::CallFunction_Startup-1 device 105 function startup failed [string "module("L_SensorMqtt1", package.seeall)..."]:107: attempt to index field 'client' (a nil value) <0x2bc43680>
01   01/12/17 22:33:26.347   LuImplementation::StartLua running startup code for 105 I_SensorMqtt1.xml failed <0x2bc43680>


Thanks!
Title: Re: MQTT Client Plugin
Post by: vosmont on January 14, 2017, 11:14:38 am
I've installed this using the great instructions provided but it is failing... anyone have any idea what this means:

01   01/12/17 22:33:26.347   LuaInterface::CallFunction_Startup-1 device 105 function startup failed [string "module("L_SensorMqtt1", package.seeall)..."]:107: attempt to index field 'client' (a nil value) <0x2bc43680>
01   01/12/17 22:33:26.347   LuImplementation::StartLua running startup code for 105 I_SensorMqtt1.xml failed <0x2bc43680>


Thanks!

I think that the MQTT library is not installed.
You have to copy the files "JSON.lua", "mqtt_library.lua" and "utility.lua" in "/usr/lib/lua".

If you get my modifications, you don't have to put the "JSON.lua" file.
Title: Re: MQTT Client Plugin
Post by: vosmont on January 14, 2017, 11:19:58 am
I've added action "Publish", to be able to publish from LUA code.

https://github.com/vosmont/vera-mqtt
Title: Re: MQTT Client Plugin
Post by: castrov on January 17, 2017, 09:00:01 pm
The files were in there originally... but I still receive this error.

Any other ideas?  What do you mean by your modifications?  I grabbed all files from https://github.com/vosmont/vera-mqtt

Thanks!

root@MiOS:/usr/lib/lua# ls -l | grep "Jan 12"
-rw-r--r--    1 root     root         49510 Jan 12 20:56 JSON.lua
-rw-r--r--    1 root     root        272996 Jan 12 20:56 mqtt_library.lua
-rw-r--r--    1 root     root         93149 Jan 12 20:56 utility.lua



I've installed this using the great instructions provided but it is failing... anyone have any idea what this means:

01   01/12/17 22:33:26.347   LuaInterface::CallFunction_Startup-1 device 105 function startup failed [string "module("L_SensorMqtt1", package.seeall)..."]:107: attempt to index field 'client' (a nil value) <0x2bc43680>
01   01/12/17 22:33:26.347   LuImplementation::StartLua running startup code for 105 I_SensorMqtt1.xml failed <0x2bc43680>


Thanks!

I think that the MQTT library is not installed.
You have to copy the files "JSON.lua", "mqtt_library.lua" and "utility.lua" in "/usr/lib/lua".

If you get my modifications, you don't have to put the "JSON.lua" file.
Title: Re: MQTT Client Plugin
Post by: vosmont on January 18, 2017, 04:16:22 am
New version on github (check the loading of the MQTT library)

@castrov, can you try to copy again the dependencies ?
The file sizes are weird.

on my Vera :
Code: [Select]
root@MiOS_xx:/# ls -lrt /usr/lib/lua

...

lrwxrwxrwx    1 root     root            28 Sep 24 21:23 dkjson.lua -> /mios/usr/lib/lua/dkjson.lua
-rw-r--r--    1 root     root          5989 Dec  5 23:28 utility.lua
-rw-r--r--    1 root     root         29819 Dec  5 23:28 mqtt_library.lua
Title: Re: MQTT Client Plugin
Post by: funstuff234 on January 30, 2017, 11:00:42 pm
Some modifications :
https://github.com/vosmont/vera-mqtt

You can subscribe to a topic by creating a child device :

1/ Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
2/ Reload LUUP engine.
3/ Change the attribut "id_parent" with the id of the MQTT plugin device.
4/ Reload LUUP engine and refresh your browser.
5/ You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
6/ Set the topic you want to subcribe to and the target (format:  service,variable=(formula in LUA)).
7/ Reload LUUP engine.

If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula.

examples :


Topic  : Test/#
Target: urn:upnp-org:serviceId:SwitchPower1,Status=payload.value and ((payload.value=="alarm") and "1" or "0")

On a message from topic 'Test/Something' with payload '{"value":"alarm"}', the switch will be powered on.


Topic  : Test/+/Sensor
Target: urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.temperature and (tonumber(payload.temperature) or "0")

On a message from topic 'Test/Something/Sensor' with payload "{"temperature ":"15.2", "hygrometry":"80"}", the temperature will be set to 15,2.
Does the device type have to correspond to the Vera service we want to use? (Ex. If we want to trigger a light switch we have to use D_BinaryLight1.xml).

Also thanks for your work!
Title: Re: MQTT Client Plugin
Post by: vosmont on January 31, 2017, 03:16:35 am
Does the device type have to correspond to the Vera service we want to use? (Ex. If we want to trigger a light switch we have to use D_BinaryLight1.xml).

You take the device type you want. When a message is received, the plugin updates the given service/variable without checking that it was already defined in your device.
... so you can do what you want !  :)
Title: Re: MQTT Client Plugin
Post by: dirtbikr on January 31, 2017, 04:51:30 pm
Hello, fabulous work on this client, it is amazing! I just added my first child device using your temperature sensor example (I have a remote temp sensor reporting via MQTT with a payload of "65.73" only (whatever the temp is). The temperature is not showing up on the child device, but it does show up under the Variables tab under the variable CurrentTemperature. At the top of the page I now have the blue bar and it says MQTT Client[111]: Running Lua Startup and it never goes away (it survives Lua reload and device restart). Any ideas?

EDIT: Checked through the LUA log and realized that temperature sensors do not have an implementation file, removed that and the blue bar went away, but the sensor is not showing the temperature on the main devices screen or anywhere inside the device. The parent (111, MQTT Client plugin) is receiving the temperature and tossing it in a variable. Should I just wait and see if it figures itself out?
Title: Re: MQTT Client Plugin
Post by: vosmont on January 31, 2017, 05:46:06 pm
I've checked on my VeraEdge and on openLuup : it's ok.

Have you refreshed your browser ?
Check that target is "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=something"
Title: Re: MQTT Client Plugin
Post by: Aaron on February 06, 2017, 12:39:41 am
Anyone try getting this to interface with Osram's Lightify system?  I saw someone posted Python code for MQTT for Lightify (https://github.com/owagner/lightify2mqtt)
Title: Re: MQTT Client Plugin
Post by: dirtbikr on February 06, 2017, 04:30:49 pm
I've checked on my VeraEdge and on openLuup : it's ok.

Have you refreshed your browser ?
Check that target is "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=something"

Vosmont,

my mqttTopic is "/ESP_Office/Office TPH/Temperature" and the mqttTarget is "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.temperature and (tonumber(payload.temperature) or "0")". currentTemperature is currently populated with the value 66.76, which happened a long time ago (the most recent value in the parent plugin is mqttLastReceivedTopic "/ESP_Office/Office TPH/Temperature" and mqttLastReceivedPayload "69.08". It seems that the parent plugin just isn't handing this down to the child. It has worked successfully at least once though, as that temperature is displayed on the devices page now.
Title: Re: MQTT Client Plugin
Post by: vosmont on February 06, 2017, 04:46:13 pm
The LUA formula is made for handling complex data in JSON.

If the message (payload) is just a string, you don't have to use the formula.

your setting could be :
mqttTopic :  "/ESP_Office/Office TPH/Temperature"       (it should be "ESP_Office/Office TPH/Temperature")
mqttTarget :  "urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature="
Title: Re: MQTT Client Plugin
Post by: dirtbikr on February 06, 2017, 05:06:26 pm
I went ahead and removed the forward slash from the parent and the child. (is it necessary to click the checkbox below to make the edit successfully? I never understood what it does...) I hope I'm just doing something dumb. I went ahead and attached the variables page from the client and the child. Thank you for your help!
Title: Re: MQTT Client Plugin
Post by: vosmont on February 06, 2017, 05:24:57 pm
It seems to be OK.

You have to reload the luup engine to restart the suscription to MQTT topics.

If you want to monitor your MQTT topics, you can use mqtt-spy.
https://kamilfb.github.io/mqtt-spy/
Title: Re: MQTT Client Plugin
Post by: dirtbikr on February 06, 2017, 05:41:21 pm
I reload LUA every time I make a change and all seems to load well, but the puzzling thing is that the pdf I uploaded (the plugin) says that the last received value was 69.60 and the child is reporting 66.76. Is there a log I can view that will tell me where the disconnect is?

EDIT: I also know that my topics function as expected since I have Node-Red publishing results to thingspeak every minute: https://thingspeak.com/channels/183630
Title: Re: MQTT Client Plugin
Post by: CudaNet on March 01, 2017, 09:10:33 am
I also loaded this onto my openLuup environment, looks good so far - many thanks for that. I'll be using this for an ESP8266 NodeMCU connected directly to my mini-split systems sending updates to Mosquitto.

New version on github (check the loading of the MQTT library)

@castrov, can you try to copy again the dependencies ?
The file sizes are weird.

on my Vera :
Code: [Select]
root@MiOS_xx:/# ls -lrt /usr/lib/lua

...

lrwxrwxrwx    1 root     root            28 Sep 24 21:23 dkjson.lua -> /mios/usr/lib/lua/dkjson.lua
-rw-r--r--    1 root     root          5989 Dec  5 23:28 utility.lua
-rw-r--r--    1 root     root         29819 Dec  5 23:28 mqtt_library.lua
Title: Re: MQTT Client Plugin
Post by: dencargo on April 08, 2017, 03:08:54 pm
Gents sorry for nub question, i'm new in this z-wave world )
Will you please to help me with the BinaryLight1 issue

i have mosquitto 1.4.9-5 running on Synology. And mqqt send in topic only status of the ESP8266 switch : 1 or 0
How should I formulate the Target string in this case
mentioned example
urn:upnp-org:serviceId:SwitchPower1,Status=payload.value and ((payload.value=="alarm") and "1" or "0")
doesn't work
###
solved
urn:upnp-org:serviceId:SwitchPower1,Status=
Title: Re: MQTT Client Plugin
Post by: causalloop on April 22, 2017, 11:07:46 pm
Hi, hopefully I'm not hijacking this too much (a bit new to Vera).

If I wanted to create a device to work with your MQTT plugin - say a DHT11/22 for an MCU - that records both Temp & Humidity, how would I go about this?  (a link works too  if this has already been answered some where I couldn't find :) )

I also noticed that the equivalent humidity sensor file, D_HumiditySensor1.xml/json isn't like the temperature one.  For the URN's:
urn:upnp-org:serviceId:TemperatureSensor1 (temp)
urn:micasaverde-com:serviceId:HumiditySensor1 (humidity) ?

Though plugging that in instead of upnp doesn't work (not entirely surprised) - I think I missed/misunderstood a step...  :o
Title: Re: MQTT Client Plugin
Post by: dklinkman on April 25, 2017, 11:49:38 pm
@vosmont, thanks for improving this plugin.  I'm using both the the publish and subscribe aspects successfuly.  Not without significant effort though.  Learning is good.
Title: Re: MQTT Client Plugin
Post by: Kincaidj on May 20, 2017, 09:28:38 am
I am using this plugin to update my new to me Home Assistant. And it really is helpful. But, maybe it's me and my method of watching certain events but I noticed that to pull any temperature related sensor like Weather Underground Current Temperature or my Thermostate temp, it also is waking up my batter powered 4 in 1 sensor and sucking the battery. Does anyone know how to exclude the 4 in 1? The 4 in 1 is reporting but I don't need or want it to.

Here are some examples:
Sending [OutsideHumidity] CurrentLevel changed to 79 from 81 on topic Vera/30007658/OutsideHumidity/HumiditySensor1/30
Sending [OutsideTemp] CurrentTemperature changed to 84.6 from 83.0 on topic Vera/30007658/OutsideTemp/TemperatureSensor1/32
Sending [Thermostat] CurrentTemperature changed to 77 from 76 on topic Vera/30007658/Thermostat/TemperatureSensor1/49
Here is the 4 in 1:
Sending [_4 in 1 sensor (temp)] CurrentTemperature changed to 74 from 73 on topic Vera/30007658/46/TemperatureSensor1/46
Title: Re: MQTT Client Plugin
Post by: rmitsos on May 23, 2017, 11:53:36 am
@vosmont, thanks for improving this plugin.  I'm using both the the publish and subscribe aspects successfuly.  Not without significant effort though.  Learning is good.

About the subscribe method, can someone provide a hint on how to use a switch (virtual) with a device which speaks only MQTT ? The case is that I want to control such a device (sonoff touch) by receiving and sending actions. When I tried to create a "D_BinaryLight1.xml" seems to refuse to toggle the switch when it is used as a child of the MQTT plugin.

I think I missed something from overall process ....

Thank you
Title: Re: MQTT Client Plugin
Post by: vosmont on May 23, 2017, 01:29:26 pm
Hello,

I am using this plugin to update my new to me Home Assistant. And it really is helpful. But, maybe it's me and my method of watching certain events but I noticed that to pull any temperature related sensor like Weather Underground Current Temperature or my Thermostate temp, it also is waking up my batter powered 4 in 1 sensor and sucking the battery. Does anyone know how to exclude the 4 in 1? The 4 in 1 is reporting but I don't need or want it to.
The plugin just respond to change on variables of your devices. So if your 4 in 1 is reporting too much, you should search in the zwave parameters.

About the subscribe method, can someone provide a hint on how to use a switch (virtual) with a device which speaks only MQTT ? The case is that I want to control such a device (sonoff touch) by receiving and sending actions. When I tried to create a "D_BinaryLight1.xml" seems to refuse to toggle the switch when it is used as a child of the MQTT plugin.
The plugin was initially designed to send MQTT messages on devices' changes, by selecting some kinds of device (service/variable).
I've added the ability to subscribe to MQTT external events and change the state of a linked device in the Vera.
On the other side, the linked device (child) can not send directly MQTT message.

I will check if the modification is complex.
Title: Re: MQTT Client Plugin
Post by: Aaron on May 23, 2017, 04:02:07 pm
Guys
Ive never dug into mqtt, ever so forgive me for noobie questions.

I'm looking for an easy way to integrate vera with Homeseer. My Vera is unstable so the goal is to offload the heaviest logic (security and Occupancy) to Homeseer while having vera for the many integrated systems I use (kodi, blue iris, myq, and more)

Can this mqtt plugin send device states to Homeseers mqtt plugin (via broker) and vice versa?

Anyone done this with Homeseer before?

Thx

Sent from my SAMSUNG-SM-G935A using Tapatalk

Title: Re: MQTT Client Plugin
Post by: rmitsos on May 24, 2017, 02:52:15 am

The plugin was initially designed to send MQTT messages on devices' changes, by selecting some kinds of device (service/variable).
I've added the ability to subscribe to MQTT external events and change the state of a linked device in the Vera.
On the other side, the linked device (child) can not send directly MQTT message.

I will check if the modification is complex.

First I would like to thank for the immediate response. Now I have added a missing part on my mind about how subscribe works. But just out of curiosity that means that the subscribe method works only on existing devices, correct ? Like for instance if I have a z-wave device and use the subscribe method, I can send an MQTT message for switching it on or off  ?

Thank you

Title: Re: MQTT Client Plugin
Post by: Aaron on May 25, 2017, 02:53:02 am
I now have installed both the Vera MQTT client and Docker Eclipse-Mosquitto...  BUT I'm not finding any info on how to setup the Broker.

Docker Eclipse-Mosquitto seems to be running (log says it is listening on 1883)

BUT, I cannot find any docs on how I set it up... if I type any command into the terminal (add user, etc) no response/answer back on the terminal.

I think I need to change the Broker Username/PW and maybe setup Username/PW for the clients (I'll have 2 - Homeseer & Vera).


Thanks for any help you can give!
Title: Re: MQTT Client Plugin
Post by: MadsBrodersen on May 30, 2017, 02:50:18 pm
Thanks for your great work on this plugin.

I've been able to set it up and it's running without any problems. I can see that the broker is receiving the messages from Vera. I was hoping that I could use this plugin to control a Sonoff relay via MQTT, but I've not been able to wrap my brain around to be able to send a MQTT message that would look like this: Topic cmnd/sonoff/power and the variable is either on or off. I was thinking that I could create a virtual switch that could leverage this plugin to send the message.
Title: Re: MQTT Client Plugin
Post by: vosmont on May 30, 2017, 03:10:18 pm
I was hoping that I could use this plugin to control a Sonoff relay via MQTT, but I've not been able to wrap my brain around to be able to send a MQTT message that would look like this: Topic cmnd/sonoff/power and the variable is either on or off. I was thinking that I could create a virtual switch that could leverage this plugin to send the message.

Hello @MadsBrodersen, it's the same need as @rmitsos.
I will try to find some time to look at that.
Title: Re: MQTT Client Plugin
Post by: vosmont on May 30, 2017, 03:14:46 pm
I now have installed both the Vera MQTT client and Docker Eclipse-Mosquitto...  BUT I'm not finding any info on how to setup the Broker.

Hello, I use "MQTT Spy" to debug my MQTT messages.
https://github.com/eclipse/paho.mqtt-spy/wiki
Title: Re: MQTT Client Plugin
Post by: vosmont on May 30, 2017, 06:21:11 pm
Using state of the child devices to send MQTT messages is too complex.

But you can use the action "Publish" of the plugin in a scenario.
Title: Re: MQTT Client Plugin
Post by: xbmcnut on July 04, 2017, 05:07:36 am
I am using this plugin to update my new to me Home Assistant.
@Kincaidj I'm interested why you chose this path rather than adding the Vera component to Home Assistant?
Title: Re: MQTT Client Plugin
Post by: xbmcnut on July 04, 2017, 05:12:42 am
I was hoping that I could use this plugin to control a Sonoff relay via MQTT, but I've not been able to wrap my brain around to be able to send a MQTT message that would look like this: Topic cmnd/sonoff/power and the variable is either on or off.
@MadsBrodersen. I wrote two guides about controlling Sonoff's using MQTT that may prove helpful? http://xbmcnut.blogspot.co.nz/search/label/Sonoff (http://xbmcnut.blogspot.co.nz/search/label/Sonoff)
Title: Re: MQTT Client Plugin
Post by: parkerc on July 16, 2017, 10:49:43 am
Hi

Are there any plans to make this plugin available via the Vera App Store ?
Title: Re: MQTT Client Plugin
Post by: MadsBrodersen on July 28, 2017, 10:19:21 am
@xbmcnut. Thanks for the guides. I have my Sonoffs up and running using MQTT and Home Assistant. I'm really surprised how easy and smooth Home Assistant is in setting up and running. I seriously looking into migrating from Vera to Home Assistant


Sent from my iPhone using Tapatalk
Title: Re: MQTT Client Plugin
Post by: neptunix on August 11, 2017, 10:16:18 am
Hi everyone,


>Upload the attached files
Where on Vera FS should I put Plugin/*_SensorMqtt1.* files? I don't see any info on that. Thanks!
Upd: Found Develop Apps/Luup files -> Upload


Client can not connect to mosquitto (mosquitto version 1.4.11 (build date 2017-04-21 14:26:22+0300)). Is it a supported version?
Plugin from master (github.com/jonferreira/vera-mqtt)

client:
Code: [Select]
50 08/11/17 17:52:22.148 luup_log:14: SensorMqtt: Connecting as MQTT client: Vera-50104894 to mqttServerIp: 10.3.1.1 mqttServerPort: 1883... <0x774d4520>
06 08/11/17 17:52:22.151 Device_Variable::m_szValue_set device: 14 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Disconnected now: Connected #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x774d4520>
06 08/11/17 17:52:22.152 Device_Variable::m_szValue_set device: 14 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 0 now: 1 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x774d4520>
06 08/11/17 17:52:22.155 Device_Variable::m_szValue_set device: 14 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerStatus was: Connected now: Disconnected #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x774d4520>
06 08/11/17 17:52:22.155 Device_Variable::m_szValue_set device: 14 service: urn:upnp-sensor-mqtt-se:serviceId:SensorMqtt1 variable: mqttServerConnected was: 1 now: 0 #hooks: 0 upnp: 0 skip: 0 v:(nil)/NONE duplicate:0 <0x774d4520>

server:
Code: [Select]
Aug 11 17:52:22 ubox mosquitto[39363]: 1502463142: New connection from 10.3.1.9 on port 1883.
Aug 11 17:52:22 ubox mosquitto[39363]: New connection from 10.3.1.9 on port 1883.
Aug 11 17:52:22 ubox mosquitto[39363]: 1502463142: Sending CONNACK to 10.3.1.9 (0, 5)
Aug 11 17:52:22 ubox mosquitto[39363]: Sending CONNACK to 10.3.1.9 (0, 5)
Aug 11 17:52:22 ubox mosquitto[39363]: 1502463142: Socket error on client <unknown>, disconnecting.
Aug 11 17:52:22 ubox mosquitto[39363]: Socket error on client <unknown>, disconnecting.
Title: Re: MQTT Client Plugin
Post by: dpackham on September 21, 2017, 03:38:41 pm
so I am trying to get this to give me a report of the KWH used on my open energy monitor using MQTT values it provides

This work in OpenHab like this
Number  emonpi_ct1      "Power 1 [%d W]"    { mqtt="<[mosquitto:emon/emonpi/power1:state:default]" }
Number  emonpi_ct2      "Power 2 [%d W]"    { mqtt="<[mosquitto:emon/emonpi/power2:state:default]" }
Number  emonpi_vrms     "Voltage [%.1f VRMS]"    { mqtt="<[mosquitto:emon/emonpi/vrms:state:default]" }

I can see all the values using a spy with the below TOPIC

Topic  : emon/#

and I see number values in

emon/emontxshield/power1

how do I rewrite the Topic/Target to show these values on the CHIILD node I have created already?

Topic  : emon/emontxshield/power1
Target: urn:upnp-org:serviceId:PowerMeter,CurrentPower=payload.power and (tonumber(payload.power) or "0")

Thanks
Title: Re: MQTT Client Plugin
Post by: vosmont on September 21, 2017, 04:04:02 pm
Hello dpackham,

if the payload is just a number (not json), you should use :

Target: urn:upnp-org:serviceId:PowerMeter,CurrentPower=
Title: Re: MQTT Client Plugin
Post by: gadgetChris on October 01, 2017, 04:04:20 am
Just installed this great plug-in on a vea3-UI5, but getting:
Code: [Select]
50 10/01/17 3:51:34.332 luup_log:18: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x2bdc7680>
50 10/01/17 3:51:34.489 luup_log:18: SensorMqtt: Plugin module L_SensorMqtt1 loaded __LEAK__ this:69632 start:151552 to 0xf18000 <0x2bdc7680>
50 10/01/17 3:51:34.489 luup_log:18: SensorMqtt: Initializing SensorMqtt <0x2bdc7680>
50 10/01/17 3:51:34.493 luup_log:18: SensorMqtt: Connecting as MQTT client: Vera-30002732 to mqttServerIp: 192.168.0.62 mqttServerPort: 1883... <0x2bdc7680>
50 10/01/17 3:51:34.507 luup_log:18: SensorMqtt: Successfully connected to broker: 192.168.0.62 on port 1883 __LEAK__ this:8192 start:172032 to 0xf1d000 <0x2bdc7680>
50 10/01/17 3:51:34.510 luup_log:18: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x2bdc7680>
01 10/01/17 3:51:34.513 LuaInterface::CallFunction_Startup-1 device 18 function startup failed [string "module("L_SensorMqtt1", package.seeall)..."]:372: attempt to call field 'decode' (a nil value) <0x2bdc7680>
01 10/01/17 3:51:34.513 LuImplementation::StartLua running startup code for 18 I_SensorMqtt1.xml failed <0x2bdc7680>
I've enabled:

What am I missing?
Title: Re: MQTT Client Plugin
Post by: gadgetChris on October 20, 2017, 10:39:02 pm
Nobody can share me a clue, how to tackle this startup issue?

Thanks in advance!
Title: Re: MQTT Client Plugin
Post by: sebby on December 03, 2017, 06:27:15 pm

To simplify the NodeRed transformation, I use the MQTT identifier Vera/(SerialNumber)/(ServiceName)/(DeviceId) so I can persist all measurements (i.e. ServiceNames) to separate InfluxDB named by SerialNumber.  So I have a single measure transform for all incoming measures that are then split out into the respective databases.


Bruce, what node are you using for writing to the influxDB?  the standard node-red-contrib-influxdb node does not like the format of your parser function. i've been trying to get all sensor data into the influxDB, but whenever i select any measurement it tells me the series is empty.  i was looking over the format of the message sent to the influxDB node and all looks good.

{"measurement":"TemperatureSensor1","topic":"Vera/35#####/TemperatureSensor1/61","payload":[{"CurrentTemperature":72,"time":"1512427106000"},{"deviceId":61,"deviceName":"DOWNSTAIRS_THERM","deviceType":"HVAC_ZoneThermostat"}],"_msgid":"f3927e65.9202e"}

Any clues?

Figured it out... was not setting the message correctly in my code.
Title: Re: MQTT Client Plugin
Post by: signal15 on December 14, 2017, 04:30:55 pm
Has anyone managed to use this with AWS or Azure IOT Hub?  I'm currently using mysensors.org sensors/gateway (non-mqtt), and I'm looking at rebuilding all of this to send my data up to AWS (ideally) or Azure.

I need to not only publish data from the Vera to IOT Hub, but I also need to be able to subscribe to IOT hub and create devices on the Vera which get that data.
Title: Re: MQTT Client Plugin
Post by: dklinkman on December 18, 2017, 07:57:06 pm
AWS yes.  Azure I gave up on because I believe to make what I was doing work, I had to pay for their message hub or some middleware or something like that.  I do prefer AWS.

For AWS I believe I did set up a bridge.  On Linux that I already had running on a small board computer.  RPi would work fine but I typically use Odroid XU4.

I tweaked the mqtt client code a little bit to suit my fancy.  Nothing major.

I have several virtual devices that receive mqtt messages with effect.  A switch, temperature, humidity, string container.  It's fun to mess with.
Title: Re: MQTT Client Plugin
Post by: tellblom on February 03, 2018, 02:25:05 am
I have this setup for a lot of sensors and it all working great except one.
Device type: urn:schemas-micasaverde-com:device:DoorSensor:1
category_num: 4
subcategory_num: 1

It never gets Tripped, but on the dash board it shows like its tripped. Can't understand why I don't get anything from this device (and yes its activated under Alias)

Anyone know what this could be?
 
Title: Re: MQTT Client Plugin
Post by: PerEric on February 08, 2018, 04:18:42 pm
I have tried and tried to install MQTT using this instructions https://github.com/vosmont/vera-mqtt
I added Dependencies and Plugin and verified that it's in place.
I added a device following the instructions.
I restarted Vera Edge.

But every time it's ends upp with this:

2/08/18 21:57:26.321   Device_LuaUPnP::LoadDeviceDoc ixmlParseBufferEx /etc/cmh-ludl//D_SensorMqtt1.xml size 41234 ret 106 <0x77daf000>
01      02/08/18 21:57:26.322   JobHandler_LuaUPnP::CreateDevice_LuaUPnP failed to load 187/D_SensorMqtt1.xml so device 187 is offline <0x77daf000>

Does anyone know what the problem can be?

//PerEric
Title: Re: MQTT Client Plugin
Post by: jeubanks on February 15, 2018, 10:28:10 am
I see the purpose of this plugin is to send events from Vera to MQTT.  Is there a reverse plugin?  I have another system that is sending to MQTT and I want Vera to grab those events and apply them to a Virtual Switch inside Vera that can then be used for created rules against.

The goal, is for switching or maintaining multiple systems.  I'm coming from or trying to come from SmartThings.  I can send SmartThings events to MQTT.  Now I need to receive them with Vera and act upon them.  I have this setup currently from SmartThings to Home Assistant and I would like to have Vera be the center of my Automations collecting from other sources if possible.

Otherwise, it may seem as though Home Assistant would be the choice to be the "Center" of everything and have other systems sending data to it.  But then that leaves me with the question of what do I need Vera for then?
Title: Re: MQTT Client Plugin
Post by: dklinkman on February 15, 2018, 01:20:13 pm
The plugin can receive events also.  The payload can then be passed to a child device of the plugin.  I have tested this using a binary switch, humidity sensor, temperature sensor, and a multi-string container.  I did have to manually create the child devices and change the id_parent attribute to point to the plugin.  The plugin then creates a few variables in the child device that you can configure with a topic, and what you want to do with the payload.  In my case, for the thermometer, the topic is set to Vera/Topics/Thermometer and the target is configured with urn:upnp-org:serviceId:TemperatureSensor1,CurrentTemperature=payload.temperature and (tonumber(payload.temperature) or "0")
Title: Re: MQTT Client Plugin
Post by: jeubanks on February 15, 2018, 02:20:29 pm
Very interesting.  I'll have to take a closer look into the mqtt client then.  It's good that it's bi-directional.
Title: Re: MQTT Client Plugin
Post by: 1666man on February 18, 2018, 09:58:41 am
The plugin works good.
But I would like send a MQTT message by an another system like raspeberry/linux. For the test I use mosquitto_pub with the vera IP address and 3480 port number. The function return an error with this message 'The connection was lost'.

Have you an idea ? It's possible to send an external MQTT message to the Vera ?

Thanks in advance
Title: Re: MQTT Client Plugin
Post by: dklinkman on March 04, 2018, 08:16:23 pm
Sorry for the delayed reply.  I don't visit the forum as much as I used to.

Yes you can.  But the Vera MQTT Plugin is a client, not a broker, so you can't point your mosquitto client (mosquitto_pub is a client) to it.  A client must connect to a broker.

You can start and run your own broker on the Pi via the mosquitto package, or you can use the awesome and free Cloud MQTT broker service which is the same that I use (no affiliation whatsoever).  Or any broker you are already using will work fine too.

https://www.cloudmqtt.com/

There's some fiddling to get everything set up between the Cloud MQTT endpoint, the Vera plugin, and your pub client on the Pi.  So, to send the external MQTT message to the Vera, the mosquitto pub client on your Pi connects to the Cloud MQTT (or your own broker) and publishes a message to a topic that the Vera MQTT Plugin is listening on.  Of course the Vera plugin has to connect to the same Cloud MQTT broker (or your own) and be listening on that topic.

Btw I also like to use the mqtt-spy software (Java package, runs on my Win7Pro and elsewhere I assume) to be able to monitor things when setting it all up.  It's a client too meaning you can use it to connect to your broker and monitor the same topics and also publish messages to topics if you want.

Hope this helps explain
Title: Re: MQTT Client Plugin
Post by: scott in NH on March 06, 2018, 07:43:43 pm
Can anyone make sense of this log entry?  It is connected to the broker but no pub/sub takes place.

Thanks in advance

Code: [Select]
root@MiOS_50003670:~# cat /tmp/log/cmh/LuaUPnP.log | grep '\(^01\|^02\|^35\|^50\).*SensorMqtt'
50 03/06/18 19:09:35.620 luup_log:168: SensorMqtt: Loading plugin module L_SensorMqtt1 ... <0x764d3520>
50 03/06/18 19:09:35.680 luup_log:168: SensorMqtt: Plugin module L_SensorMqtt1 loaded <0x764d3520>
50 03/06/18 19:09:35.680 luup_log:168: SensorMqtt: Initializing SensorMqtt <0x764d3520>
50 03/06/18 19:09:35.689 luup_log:168: SensorMqtt: Connecting as MQTT client: Vera-50003670 to mqttServerIp: mqtt.synology.me mqttServerPort: 1883... <0x764d3520>
50 03/06/18 19:09:35.917 luup_log:168: SensorMqtt: Successfully connected to broker: mqtt.synology.me on port 1883 <0x764d3520>
50 03/06/18 19:09:35.918 luup_log:168: SensorMqtt: MQTT connection status changed from "Disconnected" to "Connected" <0x764d3520>
01 03/06/18 19:09:35.921 LuaInterface::CallFunction_Startup-1 device 168 function startup failed [string "module("L_SensorMqtt1", package.seeall)..."]:377: bad argument #1 to 'pairs' (table expected, got nil) <0x764d3520>
01 03/06/18 19:09:35.922 LuImplementation::StartLua running startup code for 168 I_SensorMqtt1.xml failed <0x764d3520>
Title: Re: MQTT Client Plugin
Post by: reneboer on March 07, 2018, 04:39:45 am
Hi,

I do not know the plugin but your log shows a LUA code error. File L_SensorMqtt1.lua line 377 should show a pairs command. Its variable does not have a value for some reason.

Happy debugging.

Cheers Rene
Title: Re: MQTT Client Plugin
Post by: scott in NH on March 08, 2018, 02:39:08 pm
Yes I see the error I'm hoping someone can point me in the right direction to fix it.   :)
Title: Re: MQTT Client Plugin
Post by: dklinkman on March 08, 2018, 08:29:19 pm
File L_SensorMqtt1.lua line 377 appears to be past the end of the file.  But pairs (the function) does show up in 3 places in the file.

These instances are configuration related so hard to say more without knowing your configuration

The code is trying to iterate over a list of presumed name, value pairs or something similar and hits a nil result

What do you have set up in watchdog?
Title: Re: MQTT Client Plugin
Post by: scott in NH on March 08, 2018, 08:31:47 pm
I reloaded the dependencies and now it works.  Not sure why but it's working.  Thanks!
Title: Re: MQTT Client Plugin
Post by: dklinkman on March 08, 2018, 09:05:21 pm
Well, There you go.  Congrats!!
Title: Re: MQTT Client Plugin
Post by: scott in NH on March 16, 2018, 01:34:09 pm
Thanks, now I have finally gotten the child device receiving the mqtt messages from Node Red, it turns on and off in the vera UI as expected but I can't for the life of me see how I get it to turn off the light I want to control.  The parent id is the mqtt plug in so how can I tell the child device what light to switch on an off?

Thanks!
Title: Re: MQTT Client Plugin
Post by: dklinkman on March 29, 2018, 12:06:18 am
The child devices are virtual (if created that way), that is, they don't represent a physical device such as a switch.  What you need is a scene that is triggered by the virtual switch, that then transfers the desired action to a physical switch or device.

For example (a working example), my virtual switch is called Mqtt Triggered Binary Switch, which is of course a child of the parent Mqtt device.  My 'on' trigger is 'when the Mqtt triggered binary switch is turned on'.  And the action is 'Garage door opener SetTarget to 0', which opens the door.  A second scene handles the 'off' trigger which is just the opposite trigger and target.

I work in AltUI so my scene/trigger/action descriptions will be a little different than in Vera native.  And note that in openLuup you have to use watches instead of triggers.  Though I haven't played with that much.

One thing I have never tried is to take an actual switch or device, and configure its parent as the Mqtt plugin.  I wonder if it would then accept the mqtt variables for mqttTarget and mqttTopic, and then respond directly to Mqtt messages as you might expect.  Will have to try that one day.
Title: Re: MQTT Client Plugin
Post by: vosmont on March 29, 2018, 03:19:04 pm
@dklinkman, if you take a working switch, managed by the Vera, and change its parentId... it will work no more, as the Vera won't be able to control it.
Title: Re: MQTT Client Plugin
Post by: dklinkman on March 29, 2018, 09:46:19 pm
@vosmont,  Thank you for saving me from a potential forehead slap moment.  I'm not sure I would have actually tried it.  Was more of a random idea.
Title: Re: MQTT Client Plugin
Post by: scott in NH on April 02, 2018, 02:34:48 pm
The child devices are virtual (if created that way), that is, they don't represent a physical device such as a switch.  What you need is a scene that is triggered by the virtual switch, that then transfers the desired action to a physical switch or device.

Thanks exactly what I needed to know!!



One thing I have never tried is to take an actual switch or device, and configure its parent as the Mqtt plugin.  I wonder if it would then accept the mqtt variables for mqttTarget and mqttTopic, and then respond directly to Mqtt messages as you might expect.  Will have to try that one day.

I have tried that and can tell you it does not work!
Title: Re: MQTT Client Plugin
Post by: peppemon on April 25, 2018, 05:30:26 am
Thanks a ton for this plugin. I have 4 iPads wall mounted around the house and I have created an IOS APP to control everything.
The plugin allowed me to move from a poll implementation to a push implementation in order to update the devices status. This saves a lot of computation.

The only issue I have is that I do not get any MQTT message when a scene is triggered. Ideally I would like to get that as well (example: when I run "leaving home scene" all the iPads will dimm the screen to 0%), but no matter what I select, no MQTT messages are sent when a scene is triggered.

Is there any way to do that? Can this functionality be added?
Thanks a ton again!
Title: Re: MQTT Client Plugin
Post by: riz94107 on May 28, 2018, 02:05:54 pm
This plugin (specifically, from https://github.com/vosmont/vera-mqtt ) seems to be exactly what I'm looking for, and I managed to get it installed, and my MQTT broker is already up and working for other stuff, but I'm having trouble with a few things from the README:

- "Set desired variable watches on the Watchdog tab"  I didn't know what "Watchdog tab" refers to - but I see in the Variables tab a var called mqttWatches - which I assume is where to set a variable watch.  An example here would be helpful... I'm sure I'll figure it out eventually.  EDIT:  after playing around for a few minutes, a "Watchdog" tab miraculously appeared.  Huh.

- likewise an example of setting and using Alias would be helpful too.

the subscription examples seem better, though there are some pieces missing that probably make sense to someone who has worked more closely with lua and devices (specifically the urn).

There seems to be a lot of info scattered throughout this thread - I'm still combing through it, but a Quickstart guide would be really, really helpful.

I have not yet actually gotten Vera to connect to my MQTT broker, but I'm hopeful!  Thanks again @vosmont and @SchattenMann and all the others who have contributed over the last couple years.
Title: Re: MQTT Client Plugin
Post by: riz94107 on May 28, 2018, 05:24:41 pm
This plugin (specifically, from https://github.com/vosmont/vera-mqtt ) seems to be exactly what I'm looking for, and I managed to get it installed, and my MQTT broker is already up and working for other stuff, but I'm having trouble with a few things from the README:

- "Set desired variable watches on the Watchdog tab"  I didn't know what "Watchdog tab" refers to - but I see in the Variables tab a var called mqttWatches - which I assume is where to set a variable watch.  An example here would be helpful... I'm sure I'll figure it out eventually.  EDIT:  after playing around for a few minutes, a "Watchdog" tab miraculously appeared.  Huh.

- likewise an example of setting and using Alias would be helpful too.

the subscription examples seem better, though there are some pieces missing that probably make sense to someone who has worked more closely with lua and devices (specifically the urn).

There seems to be a lot of info scattered throughout this thread - I'm still combing through it, but a Quickstart guide would be really, really helpful.

I have not yet actually gotten Vera to connect to my MQTT broker, but I'm hopeful!  Thanks again @vosmont and @SchattenMann and all the others who have contributed over the last couple years.

It has connected to the broker, and I can see various Vera/Event/*  updates, and figured out the Alias stuff.  I'm getting stuck on getting a working virtual device which reflects MQTT topic changes.

I created a device (from Apps->Develop Apps->Create Device - is there a better place?) which has the SensorMQTT device id in the parent ID.  I appear to have gotten the device to subscribe to the topic I'm interested in (the broker is sending topic messages to Vera, so I assume that bit is set up), but I'm not sure where to look for troubleshooting my virtual device.

I set it up using D_MotionSensor1.xml, as it's a motion detector (I wrote the firmware on this device and can change as needed).  The Message it sends is either { "Status": 0 } or { "Status": 1 }, depending whether it's triggered or not.  I've got mqttTarget set to

urn:micasaverde-com:serviceId:SecuritySensor1,Tripped=payload.Status and ((payload.Status=="1") and "1" or "0")

and mqttTopic is sensor/motion, which is correct, and caused the broker to start sending messages on that topic.

...but as far as I can tell, nothing ever changes with the device, even though I can see the messages being sent.  Where do I look for more debugging info?


EDIT:  Would still love more debugging info, but after I changed mqttTarget to urn:micasaverde-com:serviceId:SecuritySensor1,Tripped=payload.Status
things started working.
Title: Re: MQTT Client Plugin
Post by: halo on June 02, 2018, 08:11:51 pm
Hi,

I would like to replace the payload answer from number to string and additionally put some if clauses. Is it possible using only MQTT target field?

For example :
received payload=1, put into variable 1="Heat"
received payload=2, put into variable 1="Standby"

I have tried below, but failed.

Code: [Select]
urn:upnp-org:serviceId:VContainer1,Variable1=payload and payload=="Grzanie" or "20" and payload=="Dupa" or "30" and payload=="Zamarzanie"
Please suggest some solution

EDIT : Case closed. Workaroud applied.
Title: Re: MQTT Client Plugin
Post by: halo on June 11, 2018, 02:46:11 am
Hi,

The plugin works pretty stable and OK.

There is only one problem. The Client will not automatiacally reconnect to broker after restart of broker.  It needs to be done manually using "Engine Restart".

Can you please help to solve this?

What could be the potential solutions for that?
Title: Re: MQTT Client Plugin
Post by: avalon on July 02, 2018, 03:35:04 am
Hello,

First of all thanks for the fantastic plugin, I've used it for a couple of months and everything worked wonderfully.

But in the last few days I had a problem.
I moved the Vera on a 4G router because at the moment my isp's network is not working properly, but the Vera doesn't seem to send any of the message. I connected and tested the internet connection and it works fine, but when I can't receive any message from the controller.

Have someone experienced this before? Do you know how to solve this problem?

PS. Sorry if my english is not flawless, but it's not my first language.

Thank you in advance for the reply and have a nice day,
Simon