A suggestion for an “offline” API

[wz2b]

Some time ago I asked about querying the Vue 2 using BLE GATT.  I never got a clear answer on whether or not that’s possible, but I was told that Emporia didn’t want to have to make that API “public stable.”  I disagree with that philosophy (you can do your best on maintaining compatibility, then document where it’s not possible).  But it occurred to me that this isn’t really necessary; there’s a simpler way to do it.

I have a weather device called a WeatherFlow.  It is excellent.  Like the Vue, the sensor itself speaks bluetooth to a device inside the house that acts as a gateway to the IP network.  So, same basic communications topology.  They also don’t want to expose their BLE over-the-air protocol.  So what they do is they have the gateway just spit out UDP messages every few seconds to the broadcast address on whatever LAN they’re connected to.

Client data collectors on site can just open up a UDP socket listening on that port and parse the messages.  One really nice thing about that is you can have multiple receivers.  You can do things like set up a RPi display (or a few) or write an agent to directly drop that data into InfluxDB or Prometheus.  You can do pretty much anything.  But it’s very, very, very simple.  There is no real API documentation beyond the message format (because no more than that is necessary).  There’s no logging in, no REST service descriptions, no registering notification endpoints, nothing.  If you wanted to write a small agent that received these UDP messages and relayed them to an MQTT broker, great, that’s probably a 10 line python program.

For this device, there’s not really all that much data.  You have a voltage and n channels of either power or current.  I think some kind of tagged message format like json would be ideal, though with UDP message length limitations you’d have to work through how much you can fit in a single UDP packet (and it’d be nice to have a single report be a single packet if possible).  I think you do want that line protocol to be extensible.  I would include the MAC or serial number of the sending Emporia device and some kind of protocol version byte.  I would also make it text (not binary) because then you can use just ‘netcat’ to look at it and debug.  I think if it’s done right a developer would be able to figure out the meaning of the messages with zero documentation.  I would love to have input on or help design the format.

I think this what Emporia should do first.  For me that’s an even higher priority than a public cloud access API.  And whatever microcontroller is in the emporia gateway device it can certainly send UDP messages.  You can generate JSON with string concatenation, but if that’s too complicate, send lines of CSV, or even just one line of CSV with a few fixed columns and then the remaining columns are powers for however many channels a particular flavor of device has.  (Interpretation would be a little more complicated for single vs three phase devices that way).

So Emporia, what do you think?  If the answer is “we don’t have bandwidth” then send me an NDA and I’ll implement it for you, no charge.  I’m an embedded systems developer with an electrical engineering background, and this is that important to me.

 

 

[wz2b]

I need to edit what I wrote a little, but don’t see an obvious way to do that so I’ll just issue a correction:

Like the Vue, the sensor itself speaks bluetooth to a device inside the house that acts as a gateway to the IP network.  So, same basic communications topology.

I conflated the Vue2 with my Weatherflow product and said the wrong thing.  The Weather Flow is actually 2 pieces and uses BLE between them. The Vue 2 obvious is not that, it’s Wifi right out of the panel.  The rest of what I wrote still makes sense.  If the device is on 192.168.1.0/24 then broadcast UDP messages to 192.168.1.255 and anybody on that LAN that wants to listen for them can do so.  You could make it so you could turn these broadcasts on and off if needed, though I don’t see a lot of harm in just leaving them on always.

[schanders]

Hi @wz2b can you contact me schanderbally at gmail. Based on your replies for local access. Thanks!

[nateguchi]

+1 for a UDP local API. This would make the product much more attractive and mirrors what the Owl range of energy monitors does.

Emporia happen to have the most capable unit in terms of circuits monitored but least capable in terms of integrations when compared to its peers.

Such a shame

 

[Author]

Posts