Command line access to UI available data

Configuration
1

In the UI I have this card with Wyze entities on it
ScreenHunter 629
If I click an entity, I get this information.
ScreenHunter 630
The battery information is not exposed as a sensor, but I’d like to access it. The only way I found is to turn on debug, and go trip the sensor, then log scrape, essentially the opposite of automation. Is there anyway I can run some sort of script to extract this information ? I am not interested in displaying it, just processing it. Thanks

2

You can make a template sensor:

sensor:
  - platform: template
    sensors:
        master_battery:
          value_template: '{{ state_attr('sensor.my_wazedevice', 'battery_level') }}'
          unit_of_measurement: '%'

replace sensor.my_wazedevice with the correct sensor name and master_battery with the name you want. You can find this in the Developer Tools tab under sensors, and you can debug this quickly under template.

2 Likes
3

That’s one solution. However, a better value template would be

"{{ state_attr('sensor.whatever', 'battery_level') }}"

See here for why.

@ob2s What would you like to do with this info? If you want to use that value in an automation, you have a few options depending on what you want to do. What would you like to do with this info? A template sensor might not be necessary. For example, if you wanted to make a “low battery” notification you could use a numeric state trigger that references that attribute.

1 Like
4

Good catch, I’ll update it

5

The sensor appears in developer tools as

binary_sensor.wyesense_77892e58'

So I put ?

value_template: "{{ state_attr('sensor.binary_sensor.wyesense_77892e58', 'battery_level') }}"

@Tediore I wanted to to be able to poll this data with an external script, but an automation that notifies on a threshold is good. Thanks

6

You put whatever the entity ID is, in this case binary_sensor.wyesense_77892e58 (did you mean binary_sensor.wyzesense_77892e58?)

With an automation like I described it’s a little different though. In that case, use a numeric state trigger referencing that entity ID and whatever threshold you want, and for the value_template use {{ state.attributes.battery_level }}

7

Thanks, it is showing None%. I’d really like to get the battery info from the command line (pi). Is this a hint how to do that from the debug log ?

2020-04-29 09:57:14 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.2878919216] Received {'type': 'config/entity_registry/get', 'entity_id': 'binary_sensor.wyzesense_77892e58', 'id': 21}
8

Check that the entity ID is correct then. What is your ultimate goal here though?

9

My goal is a weekly battery report. At this point every Sunday night I will turn on debug, then reboot, let it run for 5 minutes, set back to Warn and reboot. While on debug, I run this, because it is in the log at startup.

grep battery_level home-assistant.log |grep wyze |awk '{print $14":"$16}' | awk -F= '{print $3"="$2}'|sed -e "s/,:friendly_name//g" 
Door1=99
Garage=87
Office=87
Back=94
WyzeSwitch=90
Master=93

it is a terrible way to do it, because it requires 2 reboots, but I don’t see another way. The entity is correct, I copy and pasted it from the supervisor. I guess the biggest problem is my ignorance. Thanks for your help.

10

Try this:

1 Like
11

Thanks paddy, I will see if I can have better luck configuring mqtt (prereq) first, and give it a go.

Edit: hass-cli is my freakin’ new best friend !!!
Cli Llink

# hass-cli -o yaml state get binary_sensor.wyzesense_779aae2a
   -  attributes:
          assumed_state: true
          battery_level: 87
          device_class: door
          friendly_name: 2Garage
          mac: 779AAE2A
          rssi: -87
          timestamp: '2020-04-29T07:42:56.757000'
      context:
          id: 65a83c6c3c22498b82ca73f33c4bea64
          parent_id:
          user_id:
      entity_id: binary_sensor.wyzesense_779aae2a
      last_changed: '2020-04-29T17:33:37.257402+00:00'
      last_updated: '2020-04-29T17:33:37.257402+00:00'
      state: off

Great stuff. thanks of everyone’s help.

12

I see you are using HA for two, three months now, right? I can remember, how confusing things are, in the first stages of addiction… :smiley: :smiley: :smiley:

If I may, and this is not meant intrusive. You should avoid to go to deep in CLI commands and such “special things”. In HA you can normally do most things with automations and some yaml code. There are only a few places, where it is needed.

This is not a no-go, but in my experience it is way better, to stick with the routines. HA is moving fast, some things will get dropped, a lot of new things come on board, in most cases there is some support for moving things to the “new way”, but normally not on OS level. And if you have to change the underlying system, like moving from a normal install to a docker install, all these nice little CLI thingies don’t work anymore… :frowning:

What I want to say is, for your goal, there are a lot of choices to get to it, so CLI is just one of them. I would do it with an automation that goes through all the battery states at, let’s say Saturday evening. :slight_smile: Please do not misunderstand me, it is not the wrong way, to do it via CLI, it’s just not the way, most people would do it in HA, hence it will slow you down at one point in the future.

And why would you have trouble to setup MQTT? What’s the problem? :slight_smile: MQTT will be another new friend of yours. :wink:

Oh, and lastly, would you mind deleting the other thread regarding thios question here in this thread? Thanks a lot!

Keep it up, but don’t make it too complicated. :wink: Ask, why I know, that a *nix background doesn’t do you any good with HA… :smiley: :smiley: :smiley:

1 Like
13

Bit late to the party, but your sensor is not working because the entity_id is wrong

your wrote

sensor.binary_sensor.wyesense_77892e58

but it should only be

binary_sensor.wyesense_77892e58

14

Thanks, I did get that corrected as shown in the debug line, but I have embraced hass-cli until it stops working :wink: