Curl > json command

Yes, that is possible, but not very nice…check tester and multi-functional below:

55

It takes out the toggle, which i could live with, (replaces it with an active and inactive lightning bolt) but it stops communication from the switch to the frontend. Iow, one can switch from within HA successfully, but if the switch is toggled manually on the hardware-switch, it doesn’t show in the front end.

Which leads me back to the question if we can adjust the polling time of the state command_line?

to be complete, this is the code right now, i left the logical test intact hoping it would see it, but i think it isnt used now since ive taken out the State command:

    sw_tester_cl:
      friendly_name: 7 - Tester
      command_on: >-
        curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"on"}}' http://192.168.xxx.xxx/iungo/api_request
      command_off: >-
        curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"off"}}' http://192.168.xxx.xxx/iungo/api_request
#      command_state: >-
#        curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"4e6eeb01", "prop":"state"}}' http://192.168.xxx.xxx/iungo/api_request
      value_template: >-
        {%- if value_json.rv.value == 'on' -%}
        {{ true }}
        {%- else -%}
        {{ false }}
        {%- endif -%}

    sw_multi_functional_cl:
      friendly_name: 8 - Multi Functional
      command_on: >-
        curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"7b4d9b1b", "prop":"command", "value":"on"}}' http://192.168.xxx.xxx/iungo/api_request
      command_off: >-
        curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"7b4d9b1b", "prop":"command", "value":"off"}}' http://192.168.xxx.xxx/iungo/api_request
#      command_state: >-
#        curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"7b4d9b1b", "prop":"state"}}' http://192.168.xxx.xxx/iungo/api_request
      value_template: >-
        {%- if value_json.rv.value == 'on' -%}
        {{ true }}
        {%- else -%}
        {{ false }}
        {%- endif -%}

ive tried this workaround by creating binary sensors based on their usage, and show these in the frontend as extra-badges:

02

As you can see it gets very crowded, and yet, the switches report incorrectly. Binary sensor and usage show Off or zero , while the bolt is highlighted and the multi_functional icon is hot.

Back to original quickly :wink:

Thanks,
Marius

That’s expected because you’ve removed Home Assistant’s ability to track the state of the switch.

The docs don’t mention it and I don’t see anything in the code that suggests it’s configurable.

or posts crossed…

As you can see ive been trying the binary sensor. That seems to update in a more relaxed frequency, implying the system should be able to take it easier…

Would this be a @balloob question, or where else should i post this, you know?

Thanks,
Marius

You could use Template Switch - Home Assistant to combine your command line switch and your binary sensor into a switch that infers its state from power usage. It still won’t be accurate if the switch is on with no load attached.

HI @NotoriousBDG

yes!
I believe you pointed me to this before, but this was in the beginnings of my HA travels, and i simply couldn’t make coffee of it.
As i have a little deeper understanding now, i do see the caveat you point to, as that is exactly what is happening already with the test setup ive got . Switch is on, no load though so binary shows off…

Second thought i would have is if this testing and cross templating isnt even more prone to processor load than the current command_line switch, which is at least dead-accurate…

i feel we need something like the delay_off option for the command_line switch, just as with the binary’s:

tester:
  friendly_name: "Tester:"
#      delay_off:
#        minutes: 1
  value_template: >-
    {{ states('sensor.tester_actueel')|float > 0 }}

this is working alright, with the exception of your 0-usage issue:

33

btw, as you can see i;ve configured the binaries to need to be bigger than 0. As these happen to be fibaro plugs, the use up to 0,5 watt even when idle/off. Their meter doesn’t show…

Cheers,
Marius

Can you clarify the processor load issue you’re having? I thought you were saying your z-wave hub couldn’t handle the load, but now it sounds like you’re talking about your Home Assistant machine.

True, but i suspect it’s a bit of both:

30

I can see the RAM and Disk usage of the hassio Pi going up, (processor actually quite low…sorry for that mixup) and the system seems to get slower and slower, and i get closed tabs because of power/memory overloads in my browser window more often.


Hadn’t seen those before…

Thats why im trying to reduce unnecessary activities as much as possible. Example: im using a summary.py script thats runs on each change of a set of entities states. But it runs far more often than the actual state changes. It seemed to be triggered by those command_line state polls, which in fact are unnecessary for that summary.py. Ive change the summary to use a set of mqtt sensor-derived binaries, and things are much better on that level. Still, the state command line triggers every 15 seconds or so.

My zwave hubs publishes all events on MQTT, and then receives these command_line polls from HA. I believe there’s a fair bit of prioritizing issues between the 2, and every now and then get the max- pending error. Im not sure if thats from the Hub or the sending HA instance yet…

all in all,
hope to reduce any superfluous activity on both sides…
Marius

If you can get switch state via mqtt, you could use that to create a binary_sensor and use it for state in the template switch.

18GB disk space used sounds like a lot. You might want to check your database to see if you’re storing more history than you need…

of course! duh. Thank you! no querying the Zwave hub required, just subscribing to the published events…

check this:
regular mqtt sensors reading property: State

binary sensors reading the same property: State

this might even be better than the command_line version, since we can now use the Qos=1, making sure the message is red and delivered. Before, quite often the command wouldn’t stick because of several intermediate issues (timing, availability, sequence etc etc)

I am still a bit puzzled how to combine these into one template switch though, please give me a nudge:

this is the code i use now for a regular mqtt sensor:

- platform: mqtt
  state_topic: 'mac_address/powerswitch-zwave/4e6eeb01/state'
  name: "Tester state"
  unit_of_measurement: "State"
#  value_template: "{{ value | round(2) }}"

the code for the binary sensor:

- platform: mqtt
  name: "Tester state bin"
  state_topic: 'mac_address/powerswitch-zwave/4e6eeb01/state'
  payload_on: "on"
  payload_off: "off"
#  availability_topic: "home-assistant/window/availability"
#  payload_available: "online"
#  payload_not_available: "offline"
  qos: 1
  device_class: plug
#  value_template: '{{ value.x }}'

And the current Command_line Switch:

sw_tester_cl:
  friendly_name: 7 - Tester
  command_on: >-
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"on"}}' http://192.168.xxx.xxx/iungo/api_request
  command_off: >-
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"off"}}' http://192.168.xxx.xxx/iungo/api_request#      command_state: >-
  command_state: >-
    curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"4e6eeb01", "prop":"state"}}' http://192.168.xxx.xxx/iungo/api_request
  value_template: >-
    {%- if value_json.rv.value == 'on' -%}
    {{ true }}
    {%- else -%}
    {{ false }}
    {%- endif -%}

trying this preliminary code for starters:

- platform: template
  switches:
    switch_template_tester:
      friendly_name: "Tester"
      value_template: "{{ is_state('binary_sensor.tester_state_bin.state', 'on') }}"
      turn_on:
        service: switch.turn_on
        data:
          entity_id: switch.sw_tester_cl
      turn_off:
        service: switch.turn_off
        data:
          entity_id: switch.sw_tester_cl

Thanks!

Im not sure where to start.
my home-assistant_v2.db is only 111,5 mb. I have MariaDB installed but just admit i don’t have any idea where it is stored on the flash card…
Other than a few backups (max 3gb) and the system files, i wouldn’t know where to find the space-hogs.

Ive tried to limit the logging by entering the following in my logbook.yaml, so it doesn’t even log the sensors yet…:
include:
domains:
- script
- notify
- switch
entities:
- device_tracker.phone1,2,3,4,5,6

HI @NotoriousBDG,

Your advise was very appreciated, ive made the switches based upon the above, with a slight change in the state sensor:

    sw_tester_template:
      friendly_name: "7 - Tester"
      value_template: "{{ is_state('binary_sensor.tester_state_bin', 'on') }}"
      turn_on:
        service: switch.turn_on
        data:
          entity_id: switch.sw_tester_cl
      turn_off:
        service: switch.turn_off
        data:
          entity_id: switch.sw_tester_cl 

Customized them a bit for eye candy and functionality thanks to @andrey’s awesome customize-ui and here goes:

to the left the now truncated Command_line switches with the get state taken out, hence the bolts instead of the toggle. To the right the new template switches, working properly as they are.

My logfile has calmed down like you can’t imagine! :+1:

no more state polling every 15 seconds, and the @mviezzer 's adjusted summary.py has calmed down also :wink:

only thing bothering still is the Hassio specs growing out of hand even further…

15

anyways, thank you very much!
Marius

Very cool. You can hide the curl switches and binary_sensor in customize.yaml to get them out of your way.

For MariaDB, you can control size by setting purge_interval and purge_keep_days in the recorder component. You can also exclude any entities that you don’t care about tracking.

Personally, I use InfluxDB and Grafana for graphing historical data and limit MariaDB to 1 day because the MariaDB database gets huge fast.

To figure out what’s using all that disk space, you can ssh into the host and look around by following steps shown at Debugging the Home Assistant Supervisor | Home Assistant Developer Docs. The place you want to check out is /resin-data.

quite! it took me all afternoon but now im quite happy with the result. While i was at it, i created a few very simple threshold template_binaries also, just incase :wink:

01

i have yet to find my may in deleting sensors and switches i have created carefully in the past. For now, commenting them out and hiding in customize suffices. When im satisfied all is well and i don’t need the older definitions anymore, ill purge my config files somewhat further.

On the DB:

the thing is, i started this whole excersize because i want historical data to take me at least one year back, to be able to compare energy usage et all. Purging the DB after 1 day doesn’t help then…

I was led to believe using a real DB like Maria DB should allow me to do so?
Do you say you use both InfluxDb and Grafana ánd MariaDB?
DO Influx and Grafana take care of the longer period im looking for? If so, how do i set that up, i really really need that priority no.1 right now. Hope you care to share your setup on that.

My HA comes to a stand still and runs out of memory when i click history or logbook in the settings. Something must be amiss, and there really should be some kind of safety or security settings to prevent that.

Im still searching for a way to write the DB to an attached usb stick, this should be a possibilty, since when i browsed my flashcard I bumped into the Media folder containing usb, floppy and cdrom…

43
ive yet to find a way to point HA to those folder though.

Cheers!
Marius

1 Like

In theory it can, but not sure a PI can handle that much data.

Yes, I use InfluxDB for historical data. I use MariaDB for state restoration of input_* devices and to give me a little bit of history natively in the Home Assistant UI.

For my system, the data directory for MariaDB with 1 day of data is 374 MB and the data directory for InfluxDB with 5 months of data in InfluxDB is 534 MB.

If you want to try InfluxDB and Grafana, check out Repository: Bestlibre Addons repository.

That’s likely because your MariaDB database is so large that the PI is struggling to handle it. If you don’t want to reduce the amount of data, you might want to move to more powerful hardware such as an old PC.

Before I moved off of a PI, I used USB Boot on Raspberry Pi 3 - #37 by xbmcnut to run hassio on a USB attached SSD. When I was using it, it performed a lot better than running from an sdcard. In the end, I just have way too much stuff for a PI to handle. I now run hassio on a VM, and the performance improvement is significant.

where is this on a Hassio install?
the only data folder i can find is rather empty., and only contains ssh keys.

i am logged in as root, which is the only way i know how to ssh in to my hassio.local, and also to ftp using cyberduck, showing all files on the sd card (i think)

btw, my home-assistant_v2.db file is so small (113mb) because after i installed the MariaDb it never changed :wink: can’t be the troublemaker.
this is my db_url: mysql://login:password@core-mariadb/homeassistant. Now where is that ?

Cheers,
Marius

Follow instructions at Debugging the Home Assistant Supervisor | Home Assistant Developer Docs to be able to ssh to the host. Once you do that, you should be able to see /resin-data in that ssh session.

My Pi B+ has been running for over a year with influxdb, so a Pi3 should handle it comfortably. I run grafana on my PC to take the graphics workload off the pi.

thanks.
what is your config for influxdb, how did you set that up? I am on Hassio and installing outside of the Hassio add-on system is somewhat complex now and then…

also, why would be the advantage of Influx over MariaDB, since the latter is offered as an add-on, i would have thought that to be the first choice of the dev’s?

Cheers,
Marius

HI @NotoriousBDG,

please let me get back on this for a bit. Since ive made these changes ive run into a new sort of trouble… my binary state sensors don’t get updated very often of course, since they’re always on. somehow, this is not always seen, and all of my sensors show off, while my threshold_sensors, that measure the real power usage show they’re on, because they are using power.
Since the binary state sensors are used in the rest of my system, and automations, this causes big trouble, which not even a host reboot solves all the time.

Could this have to do with the recorder bit of HA? I’ve also tried to reduce the history/logging of HA shortly after i had changed the template switches/sensors you helped me with.

If so, would you know how to be sure these template sensors stay populated? I should not be an issue of the mqtt events, since they are published with the retain value. I do have qos set to 1, maybe i should change that?

just for completeness here’s the template:

sw_tester_template:
  friendly_name: "7 - Tester"
  value_template: "{{ is_state('binary_sensor.tester_state_bin', 'on') }}"
  turn_on:
    service: switch.turn_on
    data:
      entity_id: switch.sw_tester_cl
  turn_off:
    service: switch.turn_off
    data:
      entity_id: switch.sw_tester_cl

and the binary sensor:

- platform: mqtt
  name: "Tester state bin"
  state_topic: 'mac_address/powerswitch-zwave/4e6eeb01/state'
  payload_on: "on"
  payload_off: "off"
#  availability_topic: "home-assistant/window/availability"
#  payload_available: "online"
#  payload_not_available: "offline"
  qos: 1
  device_class: plug
#  value_template: '{{ value.x }}'

the #-commented lines are not mine, their were in the example code I that don’t fit in my setup

the command_line switch

sw_tester_cl:
  friendly_name: Tester (cl)
  command_on: >-
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"on"}}' http://192.168.xxx.xxx/iungo/api_request
  command_off: >-
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"4e6eeb01", "prop":"command", "value":"off"}}' http://192.168.xxx.xxx/iungo/api_request#      command_state: >-
#      command_state: >-
#        curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"4e6eeb01", "prop":"state"}}' http://192.168.xxx.xxx/iungo/api_request
  value_template: >-
    {%- if value_json.rv.value == 'on' -%}
    {{ true }}
    {%- else -%}
    {{ false }}
    {%- endif -%}

Please have a look if you would,
Thanks,
Marius

Influxdb is a time series database, designed to store series of data, and so is much more efficient at it. MariaDB is a relational database, which is good at storing complex relationships, but at the cost of efficiency for relatively simple tasks like this.

I have not used Hassio, but I would be surprised if there isn’t an addon for Influxdb.