[PowEEr]

You wouldn’t need to rewrite the ESP32 FW… just man-in-the-middle.  I haven’t looked yet (I’ve only had the system installed for 24 hours), but I doubt the protocol protects against that vector.  Of course it is against their ToS.  Honestly rewriting the ESP-32 FW wouldn’t be too difficult… it’s obviously just a multiplexed ADC cycling through the sensors.  I haven’t looked to see which uP they’re using, but writing new FW wouldn’t take more than a week… if Emporia ever folds (e.g. after introducing a subscription model), I’ll happily take on that project.  As-is the software experience is just barely usable enough for me to not invest that effort.

[PowEEr]

I’d say just allow the user to decide whether or not to display/include the balance in calculations.

[PowEEr]

Or make a public API to access V/I on each sensor and we’ll make the app for you.

[PowEEr]

Yes, and also just to display the data (if desired).  Seeing V/I/P (and possibly even power factor) would be awesome!

[PowEEr]

I agree… the low hardware price and nonSAAS model is probably a loss leader to sell usage data to 3rd parties.  I’d very much love an API that didn’t require cloud connectivity at all.  It probably wouldn’t take too much effort to man-in-the-middle the host/client session, although this is nominally against their ToS.  I’d much rather this unit talk to a Raspberry Pi versus a monetized cloud service.  Still, even a public API – that still required cloud connectivity – would be better than nothing.

[PowEEr]

I’m an electrical engineer in Chattanooga.  Our local utility has a smart grid power monitoring system, but it only monitors the main lines and doesn’t support 3rd party units.   purchased two units and for the price the hardware is impressive.  It is painfully obvious that the hardware is a loss leader… obviously our data is valuable to marketers, who are subsidizing the hardware cost.  I worry that eventually emporia might add a subscription service, which is a non-starter to me.  We’ll see; I want them to be successful, but I worry that the hardware is too cheap to sustain itself long term.

I don’t have too much feedback on the hardware… it’s really good.  The clamps are well-built and the current accuracy is close enough for a consumer device… I wouldn’t trust it in a financial setting, but obviously that’s not what it’s being used for.  It does everything it needs to do and for the cost it can’t be beat.

…

But onto the software… boy does that need work.  In no particular order:

-Y’all need a public API.  Bad.  And soon.

-Your program obfuscates too much.

-You need to list units next to numbers (and also use the correct units).  It’s glaringly obvious that when I select “Watt” the app is actually showing kW… but without units how do I know?  Also I have yet to find descriptions on how “gal of gas” (~120E6 Joules) is supposed to represent power (J/s).  Is this “gallons of gas per hour?”  Same for “Car mile…” is that per hour?  What about CO2, is that grams/hour, pounds/year.  And the worst off, what on earth is “trees” as a measure of power; I can’t even fathom a guess.  If you enumerate what these are supposed to mean, I haven’t found it yet and I’ve spent a couple hours reviewing the documentation… most users would give up after maybe 20 seconds.  After selecting an obscure unit, the App UI shows “Energy used in G…”  but that’s all I can see… clicking on the text doesn’t do anything (using iOS).  I can just imagine John Q Public setting it to “trees” and then gloating to his friends “I saved 245 trees this year…” oblivious to what that means.  I get that y’all are trying to excite Mr. Public about boring concepts (to non-EEs), but at least explain the concepts you’re trying to abstract power into (and also please use the correct units).

-Your “multiplier” method of tapping full-phase circuits (A-to-B) is not good.  Your FAQ briefly mentions that current returning to the split neutral isn’t included (correct), but how do you expect the typical customer to understand this?  Worse though is that the multiplier is applied to the raw current measurement, which makes the current measurements incorrect… of course the multiplier is needed to make the power consumption correct, but the issue isn’t actually the multiplier… it’s just how it’s applied in software.  The multiplier should be applied to the input voltage, not the current… that’s ACTUALLY what the multiplier is correcting (i.e. 240 volts versus 120 volts).  The fact that this issue was pointed out to y’all over a year ago and it’s STILL not fixed is a hint that your software project was a one-off by a 3rd party who probably knows very little about power.  P=IV isn’t a hard concept… it’s just applied wrong.  The super frustrating thing is that without a public API we’re at your mercy to update, whereas I could simply change ONE LINE OF CODE to apply the multiplier to voltage (correct), versus current (incorrect).  This is a major issue because most users would never notice this… and yet any user who chooses to display current would be off by a factor of 2 on all their 240 appliances (when single-current-monitored).  This is such a simple fix, and just shows how little effort Emporia is willing to put into fixing categorically incorrect measurement error.

-I’d like to be able to see the measured real-time voltage.  Why not display this?

-You absolutely should NOT assume the national average kWh price… the user should be asked to input this directly (e.g. “I pay 10.0 cents per kWh”), or maybe they have an option to select their utility from a list (and then you query their rates).  I bet 50% of your users don’t change the default kWh cost… I bet with your “open door” privacy policy you have access… check it out…I bet 50% of customers have left it set to the default $0.13x.  Image Mr. John Q Public, living in San Francisco, thinking his power bill will be $250 this month (@ $0.13/kWh default), and then he gets a bill for $750… his conclusion could be “well this Empora device isn’t accurate.”  So just add a pop-up to the setup process asking… the user can always just leave the default $0.13 value… but at least at that point they’ll be aware that that constant exists.

-Using multiple units in the same system is painful.  Using the ‘mains’ leads on a sub panel totally screws up the data… double counting anything in the sub panel.  Obviously you could choose to not connect the ‘mains’ leads to the sub panel, but then that’s wasting three valid channels that could be used for higher current devices (e.g. my tankless water heater is 120 amps).  Your UI needs a method to configure the ‘mains’ leads as high current leads.  That would literally be a single feature add… no major code re-write.  I’m not even asking y’all to merge all data together (in this paragraph at least)… just give an option to use the mains leads as sub leads.   Your existing “Graphed Circuit” panel is absolutely the correct way to do this… but there’s no way to drag one system as a child (sub) to the other.  It looks like your framework is there, it’s just not fully implemented.

-Merge multiple units into the same data presentation.  Why do I need to switch between the two?   Just show it all on one page.

-App should support landscape mode.  In general app entirely lacks responsiveness (UI term, not related to display update speed).

-Graph display dragging is TERRIBLE.  Beyond bad.  Entirely unusable.  I guess finger position is absolute-relative drag… but why?  Just use relative drag… what is this, CAD circa 1995?

…

OK, so it’s pretty obvious I don’t like the software experience.  I absolutely love the hardware though, and even with the glaring issues noted above, I do like this product.  The 1 second realtime power updates are amazing.  However, y’all are leaving SO much on the table.  Of course, rather than fixing these issues, y’all could just give us a public API with access to voltage/current date for each sensor and we would HAPPILY do your software job for you.

[Author]

Posts