New Plugin for Edimax SmartPlugs

---

I have written a plugin for Edimax Wifi-SmartPlugs SP1101W and SP2101W. For the latter power metering is supported. For details see README

A warning message: Logilink offers a Smart Plug, the PA0066X which looks similar and one might expect it is an OEM version of the Edimax plug. Unfortunately this is not case. The protocol is completely different and has been obfuscated. So, I won’t buy it.

Current Version

• 20171218, V0.3.19
  • Updated dependencies
  • Added incomaptibilty notice for EdiSmart firmware update

The recent firmware versions published for EdiSmart/Amazon Alexa Integration are currently not supported by pimatic-edimax:

• SP2101W: v2.09 and higher
• SP1101W: v1.05 and higher

If you have installed the new version and wish to downgrade you can use the downgrade guide provided as part of the edimax-smartplug github project.

+1 for that.
currently i read out the power meatering via CURL and then via LogWatcher.
Maybe i can help…

Looks very nice. Code look very clean an nice.

I’ve update the homepage.

Thank you very much for your feedback!

@hyperx said:

+1 for that.
currently i read out the power meatering via CURL and then via LogWatcher.
Maybe i can help…

Thank you for your offer to help with this. Much appreciated! I read about these experiments and it seems to be fairly straightforward to read the power/energy values. I have already done dome baseline work. See https://github.com/mwittig/edimax-smartplug

Some topics / ideas for future work:

• Polling the plugs for status information isn’t nice. Investigate, if Push-Notifications are supported
• Switching is fast, but it takes a long time until the result is received from the smart plug. Check response processing and do some sniffing. If it is a problem on the server-side (smart plug), notify Edimax support.
• Investigate the switch program schedule. Does it make sense to use this as part of the pimatic interface?

regarding Information about Power you need to send:

<?xml version=“1.0” encoding=“UTF8”?>
<SMARTPLUG id=“edimax”>
<CMD id=“get”><NOW_POWER></NOW_POWER>
</CMD></SMARTPLUG>

then you will get ALL the information (not only the “NOW_POWER”) as response:

Example:

<?xml version=“1.0” encoding=“UTF8”?><SMARTPLUG id=“edimax”><CMD id=“get”><NOW_POWER><Device.System.Power.LastToggleTime>20150411204110</Device.System.Power.LastToggleTime><Device.System.Power.NowCurrent>0.0207</Device.System.Power.NowCurrent><Device.System.Power.NowPower>0.07</Device.System.Power.NowPower><Device.System.Power.NowEnergy.Day>0.000</Device.System.Power.NowEnergy.Day><Device.System.Power.NowEnergy.Week>0.000</Device.System.Power.NowEnergy.Week><Device.System.Power.NowEnergy.Month>32.791</Device.System.Power.NowEnergy.Month></NOW_POWER></CMD></SMARTPLUG>

@hyperx regarding Information about Power you need to send …

Thanks for the hint. I have extended edimax-smartplug, accordingly. I have also improved error handling and extended the request handler to deal with chunked response data. I’ll update the pimatic-edimax plugin later today.

The Power metering feature is only supported by Edimax SP-2101W, while SP-1101W only supports switching. So, I think it is better to create a new device subclass, for example “EdimaxSmartPlugWithPowerMeter”, which exhibits the extended features.

What do you think?

Is this the preferred approach or would you implement everything in a single device class with fallback values?

Is it possible to implement conditional attributes & actions, e.g. attributes which are only exhibited if a certain condition like “enable power metering” applies.?

I would prefer a single device class with fallback values to keep it as simple as possible.
what do you mean with conditional actions? Do you mean inside the Ediplug ? it´s better to do this with pimatic via rules…
atm. i´m doing it with the wash-machine .— if NOW.Power goes < 15 W then Wash-mashine is ready -> send notification.

@hyperx said:

do you mean with conditional actions? Do you mean inside the Ediplug?

No, I mean conditional attributes/actions on the pimatic device instance which will be bound at construction time if some condition applies. Perhaps, the term “conditional attribute” is misleading in this context. Replace it with “optional attribute”. For example, the pimatic device will only exhibit the “powerNow” attribute then if supported by the underlying device. Using JS this would be fairly easy to implement, but I am not sure how if it can be done with Coffeescript. Anyhow, this was just an idea …

I fully agree with what you’re saying about using “Rules” in pimatic to set conditions for some switch action. This cannot be done inside the Ediplug, apart from simple schedule-based switching it provides.

I have published an update of the plugin which supports power metering.This version also solves an issue with package dependencies.

tested and working as expected !
Thanks !

it seems … i have problems with the values AND rules inside pimatic.

it seems that it doesn´t work to have a rule with "if current value is greater then…"
it is greater, but the rule won´t execute…

the rule works if you ask “if less then…”

@hyperx said:

it seems … i have problems with the values AND rules inside pimatic. …

I have tried the following which works fine for me. There is a delay of up to “interval” seconds as the plugin just polls metering values on a timeout interval basis.

{
“id”: “edimax-test”,
“name”: “Edimax Test”,
“rule”: “if currentPower of Schaltsteckdose is greater than 5 then switch Büro Marcus: Schreibtischlampe on”,
“active”: true,
“logging”: true
}

Can you please send me the rule which does not work for you?

ok this way it works…
i have used the variables inside pimatic… it seems that when you are using these values the rules won´t work.

I’ve tested rules with variables and it does not work for me either!

The variables get updated properly, however (on the Variables panel). May be this is a bug in Pimatic rather than a problem with the plugin?! Tonight I’ll also do some testing with other plugins to check if the same problem occurs.

As a work-around you can use attributes which seems to works fine.

Seems to be a known bug. See
pimatic/pimatic#580

This has also been discussed in
http://forum.pimatic.org/topic/252/variables-of-devices-not-used-in-rules/11

pimatic uses the getter function to receive the values from the plugin.

@mwittig I misses that you do not set the attribute values you return in the getters to the right values. You need to set the private attributes to the values if you receive an update like here: https://github.com/mwittig/pimatic-edimax/compare/master…sweetpi:patch-1

Also note the fat arrow, to bind the this context of the update function correctly (see coffeescript docs).

@sweetpi said:

I misses that you do not set the attribute values you return in the getters to the right values.

Thanks for pointing this out! I am about to finish a new release which will also cover this point.

The new release is available now! This release provides better error handling and also covers the issue @sweetpi pointed out on setting attribute values. @hyperx Variable expressions as part of rules like “$sp2.currentPower > 5” seem to work fine now!

• Improved robustness of the Smart Plug model detection. Now using bluebird-retry
• Make sure polling is only performed if interval > 0
• Allow for re-scheduling of updates if Smart Plug supports metering. This will trigger a new status update request if changeStateTo() has been called. This way, metering values will be updated right away when the Smart Plug has been switched
• Improved attribute change. Now, a change event is triggered only, if a value has actually changed rather than triggering the change event at each interval
• Improved error handling. Now, errors will be logged properly.
• Updated to edimax-smartplug@0.0.6
• README - fixed some typos