Emporia Community

Community Forum for Emporia

Forum Replies Created

Viewing 5 posts - 16 through 20 (of 20 total)
  • Author
    Posts
  • in reply to: A suggestion for an “offline” API #7627 Report Abuse
    wz2b
    Member

    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.

    in reply to: Allow cloudless local instance #7626 Report Abuse
    wz2b
    Member

    I wrote a separate post in the product suggestion forum but I think what I would like is to just have the emporia gateway device spit out periodic UDP updates the same as how weatherflow does it.  Look at their documentation and how simple it is.  https://weatherflow.github.io/Tempest/api/udp.html

     

    in reply to: API to pull data #7621 Report Abuse
    wz2b
    Member

     If you allowed the devices to work off the cloud, the heaviest users might get off your servers entirely.

    I agree with this, 100%.  I really hate this data going to the internet at all.  I only allow it because right now there is no other choice.

    We also intend to change the app to have it fetch data less frequently when the app is left running continuously.

    An API that has a parameter “Send all new data since time=160231015130515” is a pretty typical way to do that.  The servers should be smart enough to be able to quickly determine “there’s no new data for that device.”  Even if you had tens of millions of devices deployed, that could still be cached on a t3.medium running Redis, it should be hours to days of work to accomplish that level of scalability, not weeks or months.

     

    I really think you’re missing a few SIMPLE tricks that would make a lot of your customers a lot happier and open up new uses and value for the Vue.

    I cannot overstate the importance of what you just said here.  Saying I agree with it 100% does not adequately convey how strongly I agree.  It’s true that open systems like we’re asking for directly effect a small number of enthusiasts (hackers, nerds, whatever you want to call us).  But from Emporia’s perspective that’s not the important part.  The importance is that happy integrators and open source developers turn into evangalists and from a marketing perspective that’s exactly what every company needs.  Companies don’t need b.s. fake “viral” marketing campaigns at all (believe me, we see through those) if, instead, they have an actual community of enthusiasts evangelizing on their behalf.

    This stuff is very, very important.

     

     

    in reply to: API to pull data #7156 Report Abuse
    wz2b
    Member

    The other thing that comes to mind is bluetooth.  The setup instructions talk about bluetooth; is the device BLE?  is live data available with GATT?

    in reply to: API to pull data #7155 Report Abuse
    wz2b
    Member

    I think I want to make sure we are adding the word “local” to our API requests.  I don’t want to have to reach out to a cloud service for this.  I want rapid data, and I don’t necessarily even want it on the internet.

    1. This device says it supports ZigBee SEP, which is a standard.  Does anybody know if you can communicate with it this way – set ZigBee network parameters, keys, that sort of thing?
    2. Is there a local web interface, that might have a fetch API of some sort built into it?

     

    A  number of embedded devices like this communicate to a server that can be redirected to a local “good enough” backend.  For those looking for a local API, maybe standing up a small server on an RPi like device, that emulates the “official” backend, plus a little DNS magic would make “all local” possible.

     

     

     

     

Viewing 5 posts - 16 through 20 (of 20 total)