Direct Storage from HS Devices to InfluxDB

[Michael McSharry]

Version 5.12.0.0 adds support to store HS Device Feature values directly into InfluxDB. Any time a HS DeviceValue is set, the value will be stored in InfluxDB. Selection of the Device Features that are to be placed in this database is done by use of checkbox in the "I" column on the list of HS Device Features.

There are other means to get data into InfluxDB such as via NodeRed or via Telegraph using MQTT or other protocols. The intent of this approach is to minimize the number of components a user needs to setup and to provide an easy way to select which values are to be included in InfluxDB.



The parameters of the InfluxDB server are setup on the History tab of mcsMQTT



The HS4 plugin is at http://mcsSprinklers.com/HSPI_mcsMQTT_5_12_0_0.zip. The HS4/HS3 plugin is at http://mcsSprinklers.com/mcsMQTT_5_12_0_0.zip. Upload speeds are slow it should be available in 30 to 60 min.

The mcsMQTT manual contains additional information on InfluxDB including setup of the server for the RPi for those who want a streamlined approach. The manual is in the updater zips referenced above and at http://mcsSprinklers.com/mcMQTT.pdf

To side-load a plugin the following process is used for HS4
1. Download the zip file that is in the HS4 updater format. (e.g. http://mcsSprinklers.com/HSPI_mcsMQTT_5_12_0_0.zip)
2. Place the download in the HS4 folder.
3. Unzip the file updater_override.json and put it in the same HS4 folder.
4. With browser navigate the the HS4 plugin menu, Add option. Only HS4 plugin available will be mcsMQTT. Select it. (I do not recall if you need to deselect the current mcsMQTT version before this or not)
5. Remove updater_override.json to restore normal Updater operation.

For HS3 it is paraphrased from the HS3 SDK
1. Download the zip file that is in the HS3 updater format. (e.g. http://mcsSprinklers.com/mcsMQTT_5_12_0_0.zip)
2. Place your package installation ZIP file into the \Updates3\Zips folder.
3. Unzip updater_override.txt. I believe it goes in the HS3 folder.
3. Now go to the menu Plugins‐>Manage and click on the Refresh (Update Listing) button so it finds your updater_override.txt file and it should list your package
4. Remove updater_override.txt file to restore normal Updater operation.

[ksum]

Does this mean I need an MQTT item associated with any HomeSeer device I wish to have data sent to InfluxDB? I am interested in having z-wave switches report status and value changes but do not intend on associating them with any MQTT topics.

[Michael McSharry]

InfluxDB is independent of any MQTT traffic. You can use mcsMQTT without any MQTT associations and have only InfluxDB supported or you can have a combination of both. All I did was leverage the mcsMQTT UI to allow the user to select HS items from the Association tab and then when HS notifies that the HS device has been set then the value is routed to InfluxDB.

[ksum]

Okay, I see how it works to detect items now. Thank you.

It appears that only device features are considered as valid items for reporting, yet most of my z-wave devices are wall switches without a feature. As a result, there is no checkbox in the I column so I cannot take advantage of the reporting. I recognize this may be a restriction of capabilities and am only reporting a noted observation.

As a note, I'm running HS4 and the HS4 version of the plugin.

[Michael McSharry]

yet most of my z-wave devices are wall switches without a feature.

I do not understand how a Device cannot have feature(s) in HS4 as that was a HS4 requirement that Devices cannot contain status or be controlled.

It is not a problem for me to included Devices, but I thought that would be confusing because of the Feature requirements of HS4.

[Guest]

Yeah but the zwave hst plugin is still an hs3 one . So the ‘’old’’ hs3 paradigm still apply on those devices

[Michael McSharry]

The HS3 mcsMQTT plugin allows parent devices to be selected for inclusion. The only difference in capability between the mcsMQTT HS3 and HS4 is the support for BLE. If you want InfluxDB integration to work with the HS3 Device model then use the HS3 mcsMQTT plugin.

[ksum]

Confirming 's statement, the z-wave devices are from an HS3 plugin. Here are a couple of the devices:



I have Node Red storing some items and can wait for the HS4 z-wave plugin to report more. My use for outputting to influxdb is for graphana graphing. I have enough to figure some of that out at the moment and will move what I can to use the plugin. Thank you for the explanation and for the plugin. I do truly appreciate all the work you put into it and the support on the forum!

[Guest]

Thank you for the explanation and for the plugin. I do truly appreciate all the work you put into it and the support on the forum!

+ 1 . I think you are a very generous person Michael

[dakipro]

I just want to express my gratitude for doing this Michael, I didn't install it yet, but it is waaaay easier and more reliable way of going towards influxdb then the other routes.
Thank you Michael, all the best in the new year!

[chrisgla]

Tried PI influx connector with Influx V1.8.2 and works great!

I also tried the PI with Influx v2.0.3, and couldn't get it to work- this could be me as it's the first time I've tried V2. I created a token in Influx and PI does seem to authenticate but don't see table or measurements being created in Influx browser.

The Influx commands in the mcsMQTT manual look like they're for v1.8 as v2 doesn't seem to support "show databases" for instance. Confusingly V1.8 does support the V2 API.

An easy way to tell if you're running Influx 2.0 is to http to port 8086. v1 will give a 404 page not found error whereas V2 has a full GUI as per Getting Started With InfluxDB 2.0 - DZone Database

I also tried Influx 2.0.3 with Grafana 7.1.5 which doesn't seem to have pre-built queries for Flux yet- not sure about latest version of Grafana.

Has anyone else managed to get Influx 2.0 working with PI? If so, any hints - and does latest Grafana support Flux queries or still manual QL?

[Michael McSharry]

I think I initially tried to install the download at https://portal.influxdata.com/downloads/ v2.0.3 and ran into some issues on RPi so followed the directions I found using the prebuilt on RPi. These instructions are contained in the mcsMQTT manual. I can try again to install v2.0.3.

A POST request to /query with data "q=CREATE DATABASE bucketname" is used to create the table. I believe I was using the guidance from the InfluxDB site for V2.

Others will need the answer the questions about use in 1.8 vs 2.0. I will also accept any guidance from those who are more familiar to assure the user gets the best experience possible.

[Michael McSharry]

I tried again to install InfluxDB from the 2.0.3 download. The message I get for the ARM 64 Debian package is
package architecture (arm64) does not match system (armhf)

Researching it looks like a 64 bit (rather than 32 bit) Buster install on RPi is needed for InfluxDB V2

[chrisgla]

I downloaded the v2.0 docker image from https://quay.io/repository/influxdb/...atest&tab=tags

It’s ok to try out. I really like Docker now, Portainer simplifies upgrades once you get persistance storage sorted out and I really like being able to split things into manageable sized VM blocks.

I’ve updated Grafana to latest 7.3.6 and it still needs manual scripting for Flux queries on Influx 2.0.

Think I’ll leave any change to Influx until at least April to see if Grafana, etc has caught up with the new format.

I might dabble with the PI and Influx 2.0 to see if I can get it working- there is some query capability in the Influx GUI now.

[Michael McSharry]

I did load a 64 bit RPi image and installed InfluxDB 2 so I now have an environment to play. I noticed that username and password are now required for 2.0. My first attempt using the same credentials I have for 1.8 did not work with mcsMQTT. I'm guessing that a Token needs to be created for 2.0.

My desktop computer died yesterday so hampered right now, but can still make some progress.