[chrwei]

nice improvements!

[chrwei]

https://github.com/magico13/ha-emporia-vue pulls down to 1 minute, which i find plenty for automations.  it does have some issues, requiring a reload to work again, I’ve posted an automation that takes care of that too https://github.com/magico13/ha-emporia-vue/issues/224#issuecomment-1803935930

your creds can be used to submit data, as well as get some demographic info, still, you’re right that it’s low risk, but it’s still a concern.  The site simply lacks the warm-fuzzies of some statement about data use and privacy.

[chrwei]

I have the same questions as sarbuk, though since I’ve done extensive API usage and creation the basic usage is actually quite clear to me.  I can see less experienced people needing a guide though.

What i do find missing is examples of what gets returned.  You have nothing at all, requiring experimentation to discover it.  Examples would let me decide if this even gives what I’d need before sending my creds through your server, which as already stated is a concern.

I’m also interested to hear what you think the use case is for this.  For developers, there’s several local options on github already, many of which can easily host a local rest api.  for example, HomeAssistant has a robust rest API that can pull data from any integration with authorization tokens, which is safer than base64 encoded creds for less secure client tools.

[chrwei]

this one of my circuits, but i also tried replicating yours, and yeah, there’s something funcky on the panel

and unrelated, yours matching exactly with the solar is odd.

[chrwei]

are you sure it’s not a network/internet issue? none of my graphs have zeros like that

[chrwei]

the HASS integration is still working fine

[chrwei]

desoldering would be quite difficult, flaviu’s guide shows how to back up the stock firmware, restore is similar

[chrwei]

IO0 has to do with how ESP “programming mode” works.  it’s more than just the RTS pin, not hard, but not worth the effort for a one-off.  look up some of the ESP-01 programming adapters for examples

other than ESD damage, which shouldn’t be an issue if you ground yourself and Empoia did their engineering right, ESPs are pretty hard to brick.  there’s a basic protection circuits on each IO build into the model itself, and the bootloader is quite robust.

 

 

[chrwei]

I’d be fine with it only being done in the app, just one item that adds up all the Mains.  Right now I’m making up for it using HomeAssistant and the unofficial API using a sensor template to add them up.  the app’s graphs are nicer than HASS’s defaults though.

I’d totally be down for a BETA program.

[chrwei]

one is a Vue and the other is a Vue2, different size plugs.  I assume an adapter would work, still seems awkward, and other than experimenting I’m sure how to verify the legs.

each feeder goes out to the meter separate, I guess pealing back some sheath is possible, but I don’t think  the clamp will fit around 2 wires.

[chrwei]

port 8883 is not enough to make it MQTT.

[chrwei]

are you sure it’s actually MQTT and not just something that looks similar?  I’ve done MQTT and for constant data streams it’s either very complex to manage or you’ll end up missing data.

an SSL encrypted stream would make a lot more sense, and at its core that’s what MQTT is.  it’s all the topic stuff that makes it difficult to manage.  if you don’t have a server fast enough to pull the data from the topic before the next datapoint hits, you lose.  It’s double the overherd vs a single TCP server with no benefits.

[chrwei]

sounds like Sitesage is a “pull” api, which is more difficult to traverse firewalls with.  Emporia uses a “push” api, which is much simpler for firewalls and offline caching.

I doubt it’s actually mqtt as well, mqtt doens’t handle streams so well, but handles state very well.

 

[chrwei]

Not just Australia either!  in the “simple” midwest US we have tiered energy rates.  the $ figure Emporia provides is useless except where the grid is antique.  But that’s another post, and one exists already.

[chrwei]

a local API for things like a smart switch is fairly easy, but for an energy monitor it is not.  Gen2 might have the resources to be able to provide the last value for each interval category, but that might sacrifice resources that could be used for other things, like longer offline caching, or a higher polling interval to make features like device type detection.

what would be easiest is to have it just listen on a TCP socket and anything that connects gets real time data streamed at it.  This would take very little code or device resources, and would allow the community to step in and provide services that Emporia doesn’t have the resources for.

[Author]

Posts