Measure the power consumption via a Wemo Insight switch

[BartButenaers]

Hi folks,

I need to measure power consumption of some of my devices at home. And since I had somewhere an unused brand new Belkin Wemo Insight F7c029 plug lying around, I tried to install it. What a hell... Took me 2 hours, and - after resetting the factory defaults about 12 times - it was finally accessible via the node/node-red-node-wemo nodes. Major thanks to Dave, Nick and Ben!!!!!!!!!!!!!! Don't know how they managed to implement those nodes, because the official Belkin Android app is still not able to detect and show the damn device .

Anyway it is working now in Node-RED:

• I can turn the switch on and off.

• I can read the current state:

  

However this device can also measure the power consumption. So I had expected/hoped to have some more information in the output msg (like here), and not only the binary state of the device:

binaryState: params[0],
instantPower: params[7],
iinsightParams: {
      ONSince: params[1],
      OnFor: params[2],
      TodayONTime: params[3],
      TodayConsumed: params[8]  // power consumer today (mW per minute)
}

When looking at the wemo.js it is not clear to me what would be the best/easiest way to add this functionality to this Node-RED node. Does anybody have a tip about which approach I should use?

Thanks !!!
Bart

[BartButenaers]

When I inject a message into the Insight node, a request will be send to the device ONLY to get the binary state of the switch:

Based on this article, I had hoped to be able to get the power consumption by changing the action via the Chrome debugger:

But then then the response contains a soap error

[BartButenaers]

Had forgotton to change other things in the request:

And this:

But then I still get an Invalid Action response ...

[BartButenaers]

My time is up for today. But if I'm not mistaken, this (older) proposal from @jenavarro might have been a solution, if it would have been implemented?

[edje11]

Rule number one with these kind of plugs; Get rid of the original firmware and flash them with Tasmota.

Unfortunately this Belkin plug isn't Tasmota compatible.
For €10 you can buy on Ali a measuring plug plug with Tasmota pre installed.
It's not worth the effort to debug wemos.js, however the last is more fun and will give more satisfaction.

[BartButenaers]

@edje11

For €10 you can buy on Ali a measuring plug plug with Tasmota pre installed.

Hi Evert,
that is interesting. Would appreciate to have some more info about that. But could you please share your info (experiences, links, ...) about those plugs in a new discussion (category "hardware")? Otherwise my developments for the wemo node here will disappear in a large hardware discussion.
Thanks!

@edje11

It's not worth the effort to debug wemos.js, however the last is more fun and will give more satisfaction.

Oh it is absolutely worth the effort. Got two wemo switches a couple of years ago. Never used them, but now I want them to be functional. Otherwise I have thrown away my money ...

Anyway I added a bit of code to the wemo node, and now I get - beside the current state of the switch - a series of statistics about the power consumption

Now I will have to test this on my other Wemo switch, which hasn't got a power meter inside. Just to make sure that I don't break existing flows. Hopefully it doesn't take me more time to install that switch, compared to the time that I needed to update the code.

To be continued ...

[BartButenaers]

@BartButenaers

Now I will have to test this on my other Wemo switch, which hasn't got a power meter inside. Just to make sure that I don't break existing flows.

Damn this node works great. The Belkin app is totally not aware of my second switch, but the wemo node immediately found it:

However when I call GetInsightParams on the classic Wemo Switch (without power meter), it throws an exception. So I should call the original getSocketStatus (to only get the current switch status) on those classic switches, like in the original code.

I think I can easily distinguish between both types of switches in the start function:

• A classic Wemo Switch (= controllee) is currently mapped to type "socket":

  

• An Insight Wemo (= insight) is also mapped to the same type "socket":

  

  So I think it is better to map those latter devices to type "socket_insight".

My time is up for today...

[BartButenaers]

@BartButenaers

So I think it is better to map those latter devices to type "socket_insight" .

Quickly implemented this during my lunch break at home ...

At startup the node now detects the correct switch type (insight or classic), and - based on that type - it will only request afterwards the current state or the power consumption as a bonus:

@dceejay (and others of course): before I do a pull request tonight, are the power consumption parameters ok (i.e. useful and understandable)?

• state: Whether the device is currently ON or OFF (1 or 0)
• onSince: The date and time when the device was last turned on or off (as a Unix timestamp)
• onFor: How long the device was last ON for (seconds)
• onToday: How long the device has been ON today (seconds)
• onTotal: How long the device has been ON total (seconds)
• timespan: Timespan over which onTotal is relevant (seconds). Typically 2 weeks except when first started up.
• averagePower: Average power consumption (Watts)
• currentPower: Current power consumption (milliwatts)
• energyToday: Energy used today (Watt-hours, or Wh)
• energyTotal: Energy used in total (Wh)
• standbyLimit: Minimum energy usage to register the insight as switched on ( milliwats, default 8000mW, configurable via WeMo App)

P.S. In case there should be redundant parameters - because the e.g. can be calculated based on other parameters - it would be nice to keep those, for users (like me) that want to keep their flows simple...

Thanks!!

[hardillb]

Looks good from a really quick look.

It would be good to look at the input node output and seeing if we can make them match up in a backward compatible way. This might mean leaving msg.payload.state as the full string and moving the broken out details to under a different key.

[BartButenaers]

Hi @hardillb, nice that you join this discussion!

I have implemented your change.
Did I understand it correctly? The output msg of the Input-node now looks like this:

• For a classic Wemo Switch:

  

• For a classic Wemo Insight switch:

  

I know that backwards compatibility is very important, but the latter message still seems a bit weird to me (although it is now indeed much more aligned with the output of the Lookup-node):

1. There are now two state fields, the original as string and mine as number. I used a number, since the Lookup-node already returned a number for the state...
2. The old power field contains the same value as my new currentPower field, which might be confusing? BTW I have now also converted my currentPower field to Watt (instead of milliWatt), since everything else is also expressed in Watt...
3. The type is now "socket_insight" instead of "socket". Perhaps I should use "socket" again in the output message to avoid breaking existing flows?

[hardillb]

There is no need to duplicate any fields, you don't even need the insightParams sub object. Everything can live at the msg.payload level. Just make sure that the field names and units match when there is overlap.

[dceejay]

though having the insightParams in one block does make it easy to switch on / delete if not required etc - especially if the type does stay as "socket" so you can easily tell them apart later.

[BartButenaers]

I have now moved everything to the payload, renamed currentPower to power (for backwards compatibility), and send type "socket" instead of "socket_insight" (for backwards compatibility).

• Input-node:

  • Classic switch:

    

  • Insight switch:

    

• Lookup-node:

  • Classic switch:

    

  • Insight switch:

    

Now my finger is hanging above the 'submit pull request button', to make sure this feature remains a quick win for me

[BartButenaers]

For anybody interested in this topic, I have created a pull request.

[Roaders]

Gave up on wemo devices a long time ago. Way more hassle than they are worth!

[BartButenaers]

If you have better alternatives, please share which ones and how to read them via Node-RED...

[JGKK]

I think nowadays I would always recommend the shelly devices.
They come with mqtt build in and work completely locally.
I have had only good experiences with them and i am actually in the process of changing my complete setup to shellys.

[BartButenaers]

Johannes,
So I assume I could buy a couple of extra Shelly Plug S devices... Is there a node that I can use to read data from those plugs easily?

[JGKK]

The shelly plug s is great, I think most people here use the very well documented mqtt api with the core mqtt nodes:

https://shelly-api-docs.shelly.cloud/#shelly-plug-plugs-mqtt