New plugin for TP-Link SmartPlugs HS100 and HS110

---

@mwittig thanks, will look into that!

I hope that I find the time next week, should be doable within an evening

nice, ordered the hs110. Need to monitor some devices.

Received my HS110 today and I’ve added a device with consumption only (I don’t need switching). Don’t know if you’re interested? Otherwise I will create a PR

@sweebee Nice. Yes, push this a little bit and make a PR

I cant figure out what current is. Its related to the wattage, it doesnt increase over time. But i cant find the relation between 38w and 0.201 kWh.

Edit: okay it was a long night lol, must be amperage

I’m also adding an average value (kWh), so you know how much it uses average over an hour.

@sweebee said in New plugin for TP-Link SmartPlugs HS100 and HS110:

I cant figure out what current

Yes, that amperage. I assume you’re using the getConsumption() method of the underlying hs-100 API library which does a callout to gathering “emeter.get_realtime”. It should return the following (at least):

• voltage (V)
• current (A)
• power (W)

Apparently, the library does not implement the callout to obtain daily and monthly statistics. I’ll make a fork and you can give it a try if you like.

I through i could use the uptime as reverence for a avarage consumption. But its resetted after turning it off and on again. While the kWh meter remains the same. The kWh meter resets once you remove the HS from the socket.

.

@sweebee ok, so, the statistics data provided by HS110 may be useful. I have added support for this on my fork. Would be great if you can give it a try (simply replace the index.js file on your base, or install the fork from git).

https://github.com/mwittig/hs100-api

Note, the parameters are optional, if omitted the current year and month will be used.

/**
 * Get Daily Statistic for the given month of the given year
 * @param number [month] the number of month
 * @param number [year] the full year, e.g. 2016
 * @returns {Promise.<T>}
 */
Hs100Api.prototype.getDailyStatisticsForMonth = function (month, year) { ... }

/**
 * Get Montly Statistic for given Year
 * @param number [year] the full year, e.g. 2016
 * @returns {Promise.<T>}
 */
Hs100Api.prototype.getMonthlyStatisticsForYear = function (year) { ... }

@mwittig nice, so the device does save values like daily, monthly etc?

I’ll test it tomorrow evening. Especially daily is very useful. Tester my fridge today, 90% of the time it’s 0W, the other time it’s 120W. So a daily value gives a better indication.

@sweebee said in New plugin for TP-Link SmartPlugs HS100 and HS110:

so the device does save values like daily, monthly etc

Yes, it does. I am not sure, however, whether or not it keeps the accumulated values when it gets unplugged. Regarding the “power” value being 0W most of the time sounds a bit strange to me - well, for a fridge that may be normal behaviour though. To test the measurement unit, you can use a 60W light bulb, for example. This may be useful to check the calibration of the device and to check whether or not it indicates a constant power consumption.

Great that so many people are interested in this!

@sweebee
Thanks for the Pullrequest!
I would have added it to the HS110 device instead of adding a new device and would prefer it that way. Are there any special reasons for the extra device?

@thex @sweebee Just my two cents: For the common case, I’d prefer an extended PowerSwitch including the measurement attributes instead of having a Consumption device. See also pimatic-edimax, for example.

The reason i created a device with consumption only is that i bought the hs110 because of the energy meter. I don’t want the switching capabilities. For instance, i had it between the socket and my server, if i accidentally press off, my server will stop immediately.

But if I would use it for switching, I don’t want to see all the data, to much info in 1 device. Maybe just wattage?

@mwittig the day/month/year stats seem not to reset after removing the plug:

[ { year: 2016, month: 9, day: 17, energy: 0.25 },
  { year: 2016, month: 9, day: 18, energy: 0.615 },
  { year: 2016, month: 9, day: 19, energy: 0.238 } ]

[ { year: 2016, month: 9, energy: 1.103 } ]

For me this is the ‘best’ solution:

since i have other meters which save the value of the day every night. Like the frionius plugin for my solar panels. And a normal pulse meter for overall consumption.

@thex maybe use 2 devices? one normal switch with some basic energy values. And a energy device only with more statistics for users like me?

@sweebee said in New plugin for TP-Link SmartPlugs HS100 and HS110:

the day/month/year stats seem not to reset after removing the plug

Sounds great to me. Thanks for testing. I’ll create a PR.
EDIT: https://github.com/thexperiments/hs100-api/pull/1

We need support for something like this:

absolutely! expandable devices would be a great thing

I think there already is a way to remove the labels via config if you don’t want them.
Sure there might be the need of preventing switching the outlet but I’d rather add a config value which prevents switching it.

Maybe add a Config option to hide the switch.

I think I will have some time next week to properly add measurement.

However I’m currently experiencing some endless loops somewhere deep in the socket.io and can’t figure out where the problem is…

< 00:19:18.375 [pimatic-tplink-smartplug, TPlinkHS100] Error getting attribute value TPlinkSmartplug-3.state: Maximum call stack size exceeded
< 00:20:29.693 [pimatic] A uncaught exception occured: RangeError: Maximum call stack size exceeded
< 00:20:29.693 [pimatic]>    at Function.isBuffer (buffer.js:163:23)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:28:68)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:20:29.693 [pimatic]>    at _hasBinary (/Users/thex/Dropbox/projects/pimatic/pimatic-beta/node_modules/pimatic/node_modules/socket.io/node_modules/has-binary/index.js:49:63)
< 00:2