hass-cli event watch <single entity_id>?

[haakonstorm]

I'm loving hass-cli already. Thank you all for the great work.

The output of event watch --help

Usage: hass-cli event watch [OPTIONS] [EVENT_TYPE]
  Subscribe and print events.
  EVENT-TYPE even type to subscribe to. if empty subscribe to all.
Options:
  --help  Show this message and exit.   

It's not documented, but I tried anyways, trying to listen for state changes on a single entity:

┌───[ storm@10core ]───[ /Users/storm ]───[2019-11-12 03:37:44]
└─λ hass-cli event watch state_changed --arguments "entity_id=sensor.load_5m"
Usage: hass-cli event watch [OPTIONS] [EVENT_TYPE]
Try "hass-cli event watch --help" for help.

Error: no such option: --arguments

┌───[ storm@10core ]───[ /Users/storm ]───[2019-11-12 03:37:46]
└─λ hass-cli event watch state_changed --match "sensor.load_5m"
Usage: hass-cli event watch [OPTIONS] [EVENT_TYPE]
Try "hass-cli event watch --help" for help.

Error: no such option: --match

-- What's the syntax for doing this, if at all possible?

[maxandersen]

There are not currently an option and as I see it at the moment there is no server side api to filter per entity but it could make sense to add syntactic sugar to enable some client side filtering.

Just need to think how to make it nice as the events data can literally be anything so locating entity_id is not necessarily always in the same place as it would depend on the event_type received.

Suggestions/ideas welcome!

[haakonstorm]

Is there really no way to only listen to a particular events state change?
Perhaps this really is a job for upstream?
Or perhaps the workaround is to create an auxiliary event-type on the server that mirrors what hass-cli is watching?
It just seems malplaced for a command line client to handle a jobs like this, when it is, in fact, talking to a /server/ - right? Especially one shock full with logic for filters, events, routing and what not, raaite?
:)

[maxandersen]

remember events does not necessarily tie to any or a singular event, could be multiple ones.

for example deconz switch events are pure events with no entity id in them thus the server is not really able to distinguish in a efficient manner.

We can be a bit more creative in hass-cli and just look for a pattern, i.e. maybe a json path expression would be a nice way to do this.

something like hass-cli event watch state_changed --filter "$..entity_id=sensor.load_5m"

which would be $..entity_id as a json path that returns all attributes at any depth with entity_id attribute and then we can interpret that and say to only print a event if any of those attributes matches 'mysensor'

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.