#local_push updates

1 messages · Page 1 of 1 (latest)

gleaming elk
#

I'm trying to do the same thing - did you end up figuring it out? been trying to juggle various solutions like coordinators (per the docs), trying to figure out where to initialize the library for talking to the hardware, and making sure i know how to tell HA that there is new data.

i found the alarmdecoder integration had a simple sensor that seems to be configured for local push (based on searching the manifests), but im not quite sure where its its getting data from

velvet pasture
#

So yeah Idid end up getting started on this. It was a while back so I don't remember what integrations I used as an example.

One realization I had though was that you're still probably going to want a polling implementation even if you're planning on implementing push. The reason for this is that it's entirely possible that you will miss a push event either because HA is down, internet is down, or really just any kind of connectivity problem between the "pusher" and receiver. The only difference is how often you'll be polling and you should probably poll much less often in a push implementation.

That said, let me take a look real quick at my push implementation

#

Ok so this may vary between push implementations, but you'll want to look into webhooks

# 
    webhook_id = webhook.async_generate_id()
    webhook_callback_url = webhook.async_generate_url(hass, webhook_id)
    await hass.async_add_executor_job(create_webhooks, webhook_callback_url)

    webhook.async_register(
        hass, DOMAIN, "Whatever", webhook_id, async_handle_webhook
    )
#

I do this on entry setup

#

You generate a callback URL to pass along to whatever is going to be doing the pushing

#

create_webhooks here is just a util method I made to call the 3rd party to registere the webhook

#

async_handle_webhook is the handler for that webhook

#

I believe there are some decent HA docs about webhooks

#

But yeah basically:

  1. Generate webhook
  2. Tell 3rd party about webhook
  3. Register handler function using that webhook's id
#

I didn't get any futher than past this proof of concept, but from there it was just a matter of following through with my full implementation

gleaming elk
#

How did you arrive at the conclusion of webhooks?

#

my usecase is essentially: i noticed my thermostat has an open port that occasionally sends data whenever the compressor speed changes, i made a Python library to interpret and read that data, now i just wanna make a custom HA integration to wire that into HA.

velvet pasture
velvet pasture
#

How and where?

mellow belfry
#

You can just use a plain Python callback. An example would be the knx integration.

gleaming elk
velvet pasture
#

Is it like a websocket connection?

gleaming elk
#

No, basically just a raw socket

#

like just straight up open TCP port

velvet pasture
#

Sorry, maybe this is a gap in my knowledge, but I'm not aware of a way to connect to a socket remotely?

#

Ok, interesting

gleaming elk
#

This is all on LAN, not over the internet, i can connect and read the data and stuff with python

velvet pasture
#

Could you point me to your lib?

gleaming elk
#

Lantrane is the name on pypi

#

im mostly just lost trying to figure out the correct way to send this data to homeassistant when a new datapoint comes in

#

The manufacturer of this thermostat seems pretty allergic to integration with FOSS stuff

gleaming elk
velvet pasture
#

Yeah looks like you'd want to update your lib so that when it gets data, it would call some callback

#

So your lib would require you being able to register some callback with it

#

But yeah, I don't have experience just registering a raw callback in HA, so you'd have to poke around the docs for that

gleaming elk
#

Ah ok, thanks!

velvet pasture
#

I do still think you'd want to have polling here, right?

#

Like what if HA isn't connected when there's data published on that socket?

mellow belfry
#

If you can not only receive, but actively read the datapoints, that's no problem. Or if they are sent frequently enough... you can just postpone entity init then.

gleaming elk
#

The frequency is pretty variable, it only sends data when it changes, so if the AC is off it wont send anything

gleaming elk
gleaming elk
mellow belfry