I need a dummy sensor that can be changed from API

Configuration
1

Hi.

I need a sensor that I can change value on by contacting the Home-Assistant API. But I can’t se any good way to do this.
The most relevant I have found:

input_number: But I don’t want the values to be changed in the UI.
http_sensor: But it is not permanent, I need somthing that don’t get deleted after each start.

Any suggestion?

2

mqtt topic or sensor

3

I believe you can create an entity by posting a state in the api - it is what appdaemon uses, and through that I know that sensors can be created.

POST /api/states/<entity_id>

Updates or creates the current state of an entity.

https://developers.home-assistant.io/docs/en/external_api_rest.html#post-api-states-lt-entity-id

4

Also, there is http sensor (binary_sensor) which will be created on-the-fly so no need to define sensor at all in config.

1 Like
5

Well, it worked. but after I rebooted the server the sensor was disappeared. Just like the HTTP-Server

6

yes, but the http_sensor disappeare on reboot just like the method above

7

Can I use this? even if it is not MQTT? (no experience with MQTT though)

8

You need to setup an mqtt server that houses it. If you have hassio, it’s pretty simple. If you use hassbian, it can get complicated if you don’t know what you’re doing. As for the sensor, the topic for it will persist so the sensor will persist through shutdowns.

9

I have hass.io, but can I update the MQTT server with normal JSON POST?

10

No, you need to setup a MQTT sensor:

11

But after I set up the MQTT server, can i update it with JSON?

Anyway: I almost reach my goal with template sensor:

  - platform: template
    sensors:
      api_adminserver_disk_c_used_gigabyte:
        friendly_name: "admin-server - Brukt C:"
        unit_of_measurement: 'GB'
        value_template: "0"

Using JSON:

PS C:\Users\Administrator\Desktop> $body =  ConvertTo-Json @{"state" = "25"}
PS C:\Users\Administrator\Desktop> Invoke-RestMethod -Method post -Uri ("$ha_api_url"+"states/sensor.api_adminserver_disk_c_used_gigabyte") -Body ($body) -Header $ha_api_headers
attributes   : 
context      : @{id=cf8ecf8ecf8ecf8ecf8ecf8ecf8ecf8ecf8e; user_id=cf8ecf8ecf8ecf8ecf8ecf8ecf8ecf8ecf8e}
entity_id    : sensor.api_adminserver_disk_c_used_gigabyte
last_changed : 2018-10-16T19:47:04.051149+00:00
last_updated : 2018-10-16T19:47:04.051149+00:00
state        : 25

d
It kind of worked, but looks like the template sensor change it right back.
template_sensor

So the problem is that value_template are required, can i maybe do somthing that make this not change?

What if it sent current state as new state? will this produce a bit looping problem?

  - platform: template
    sensors:
      api_adminserver_disk_c_used_gigabyte:
        friendly_name: "admin-server - Brukt C:"
        unit_of_measurement: 'GB'
        value_template: "{{ states.api_adminserver_disk_c_used_gigabyte }}"

EDIT: Looks like the last one crashed the system on first POST.

  File "uvloop/loop.pyx", line 2591, in subprocess_shell
  File "uvloop/loop.pyx", line 2563, in __subprocess_run
  File "uvloop/handles/process.pyx", line 595, in uvloop.loop.UVProcessTransport.new
  File "uvloop/handles/process.pyx", line 130, in uvloop.loop.UVProcess._init
 OSError: [Errno 9] Bad file descriptor
12

I think you’re confusing entities and the State Machine.

The State Machine contains representations of the current state of the entities in the system. However, it can also contain anything. I.e., you can write a “state” to the State Machine that has nothing to do with a real entity. In fact, if you want to write something there, it’s better not to have it correspond to a real entity, because as you’ve discovered, the entity will overwrite what you just wrote (at some point.)

Basically, you can “make up” an entity_id and write (or update) its state in the State Machine, and that will cause a state_changed event just like when real entities update. The only rules (that I’m aware of) is that an entity_id should be a string containing one and only one period/dot, and otherwise contain only letters, numbers or underscores. (Preferably each “half” of the entity_id should start with a letter, and all letters should be lower case.) And the state string (or when converted to a string) must be no longer than 255 characters.

I would recommend you use an entity_id of “sensor.XXX” where XXX is some unique “object ID”.

EDIT: Having said all that, the states in the State Machine are not restored after a restart by themselves. They need to be written there again by something. For real entities, that’s typically done by the recorder (for some types of entities) or by the entities being updated shortly after restart (by their usual periodic update mechanism, etc.)

If you’re looking for something that will retain the state, then other suggestions made already might suit you better. I was just trying to clarify the difference between HA’s State Machine (which entities and the HA API write to), and “real” entities. Hopefully I didn’t just confuse you more.