In terms of changing the code, copy over your room IDs and check what you are doing with escaping apostrophes.
Functionality-wise, you will find it adds some additional tags to each measurement. I recommend to update the SmartApp settings as there are some new options too (e.g. to log Mode events).
I been using this for a few days and works great.
I’m using a few Aeon Lab HEM v1. Is it possible to have it log the watts from line 1 and line 2 separately instead of the total watts?
I’m sure it is. However, SmartThings doesn’t yet define any standard way of presenting capabilities for multi-channel devices. Therefore the attributes that your Aeon Lab HEM uses to represent the power from each channel (clamp) will be specific to the particular device handler you are using.
So if you want to do this, you will first need to look at the device handler you are using to find the names of the attributes you want to monitor. Then you need to edit the InfluxDB Logger smartapp yourself and add some extra attributes for the powerMeters devices.
To do this, find this line, and add in the extra attributes you want to monitor:
I’m struggling to get data logged in my InfluxDB database. I’m running an instance of Debian on a Google Cloud Compute VM with InfluxDB and Grafana services supposedly working correctly. But I can’t seem to query any data from the Influx CLI. Looking at the Live Logging in the SmartThings IDE, everything looks correct with the host IP, port, and Database name coming from the InfluxDB Logger SmartApp. Is there something different I need to do with the SmartApp code when my database isn’t on my local network? Any help is appreciated.
Edited to also add that I’m using a newer version of InfluxDB (version 1.2.1), and in this version, the Web UI is depreciated and disabled by default (they also say it will be removed in future versions), so trying to browse to :8083 returns a “refused to connect” error, but pointing my browser to :8086 returns an actual 404 page not found, which I more or less expected. My level of knowledge with Linux and CLIs is “I started literally yesterday”.
It should work as is, however you can switch the code in postToInfluxDB() to use httpPost() instead (see the comments in the code). This has the advantage that you can see any response come back, which should help to troubleshoot.
I would also check for any firewalls between the hub and your InfluxDB server. Plus triple-check you have the host, port, and database name correct (90% of the time, it’s that).
This includes support for Basic HTTP Authentication to the InfluxDB server, use of a callback function to trap errors when posting data, and various other minor fixes.
I’m also having trouble having the app go to a different subnet. It also doesn’t appear to resolve hostnames. I ‘solved’ it by spinning up an HAProxy instance on the interface connected to the hub on my pfSense router and it seems to be working.
@zcapr17 , thank you for the code and instructions. just set up an Aeon HEM Gen5 and was able to connect to influx 1.1.1 on an old netbook running Lubuntu and access it from grafana from OSX Yosemite just fine. i’ve modified your example for monitoring extra attributes but have not been able to get the format correct for the app to update (had to change code back to original). do you know if there is a known list of the names to use for the other attributes? i’ve tried the ‘powerC1’, ‘powerC2’ , albeit in conjunction with voltageC1 and VoltageC2, currentC1, currentC2, and have not had success for the influx writing.
smartthings is reporting these so i know the Aeon is sending them from the parameter codes i have set in the device handler as they show up in smartthings, just not sure of the correct naming to get them to write to influx.
Go into the SmartThings IDE, go to My Devices, then click on the appropriate device. All the attribute names and corresponding values will be listed in the section called Current States.
Attribute names are probably case-sensitive. Looks like you have current, current1, current2 at least…
looks like the names are from the events list as current1 and current2 now show up in influx, but the unit type “A” is not being assigned (is “null” in screencap), and there are two "\ " and a space in front of the value. power1 & power2 show up with the unit type also as “null” but have a numeric value instead of the string "\ " looking type.
DTH is actually this one, modified for the reporting values i want to see:
(my edits, numbers from the Aeon HEM Gen5 spreadsheet). haven’t figured out how to report kvar & kvarh, voltage1, voltage2, yet though they are included in the parameter value.
// Which reports need to send in Report group 1.
// HARD-CODED to contain kWh=1, watt=2, voltage=4, amperage=8, kvarh=16, kvar=32=total [63]:
zwave.configurationV1.configurationSet(parameterNumber: 101, size: 4, scaledConfigurationValue: 63),
// Which reports need to send in Report group 2.
// HARD-CODED to contain watts clamp 1=256, clamp 2=512, kWh clamp 1=2048, clamp 2=4096, voltage clamp 1=65536, clamp 2=131072
zwave.configurationV1.configurationSet(parameterNumber: 102, size: 4, scaledConfigurationValue: 203520),
// Which reports need to send in Report group 3.
// HARD-CODED to contain amperage clamp 1=524288, clamp 2=1048576, kvarh clamp 1=16777216, clamp 2=33554432, kvar clamp 1=134217728, clamp 2=268435456:
zwave.configurationV1.configurationSet(parameterNumber: 103, size: 4, scaledConfigurationValue: 454557696),
Ok, there are a number of issues with the DTH which are causing your problems:
The custom attributes (i.e. current1,current2, power1, power2) are not defined in the metadata section. These should be added.
When events are created they have a zero-length string for the unit. This is where they need to be defined, e.g.
sendEvent(name: "power2", value: dispValue as String, unit: "", descriptionText: "L2 Power: ${formattedValue} Watts")
// Should include the unit like this:
sendEvent(name: "power2", value: dispValue as String, unit: "W", descriptionText: "L2 Power: ${formattedValue} Watts")
Note also, the DTH does not raise events for voltage1 or voltage2, which is not surprising, as voltage meters like this tend to only report one figure anyway (all of the clamp channels are assumed to be the same voltage).