Set state without communicating with device?

Configuration
21

now you want to add a listen_state to the initialize and move that stuff to a function.

i advice you to read my tutorial :wink:

but ill give you a starting clue (you may take out the errors)

class FanSync(appapi.AppDaemon):
 
  def initialize(self):
    self.listen_state(self.blablabla, "switch.plug_158d0001a65815")

  function(self, put here what is needed):
    state = self.get_state("switch.plug_158d0001a65815", "load_power")
    sel.log(state) #dont use print(state)
    if state < 10: 
      self.set_state("fan.living_room_fan", state = "off")
    else:
      self.set_state("fan.living_room_fan", state = "on")
22

Reading away. Thanks Rene :slight_smile:

1 Like
23

ugh, very frustrating that this isnt possible without using a hack (AppDeamon) and not available within standard configs.

24

I think a switch template would work:

  - platform: template
    switches:
      skylight:
        value_template: "{{ is_state('sensor.skylight', 'on') }}"
        turn_on:
          service: switch.turn_on
          data:
            entity_id: switch.skylight_open
        turn_off:
          service: switch.turn_on
          data:
            entity_id: switch.skylight_close

I believe the state of the switch does not trigger the actions, only the actions in the UI trigger the actions.

25

Well, in all fairness, what we want to do is sort of a hack anyway - updating the internal state without telling the external component about it.

If you don’t want to use appdaemon, you can do it from an automation by calling the REST API.

26

What exactly is the wall remote in this case and where does it get its state from? This sounds like it could just be an issue in the way the wall remote is set up. Perhaps something like a template switch like @petro mentioned could work.

27

So the you can do local api calls through HA automation configs?

28

Hey - sorry to bring my own problem to this post… but I’m having an issue with the state of an input_boolean and came across this thread. It seems like the solution here could maybe work for me. Would you mind seeing if you have any ideas in regards to my issue? Performing switch/input_boolean "off action" when hass thinks it is already off. Broadlink

@magnushacker

29

Thanks. I’m gonna try this. Hopefully it works for my problem of the climate component air conditioner being turned on/off outside of HA.

30

For future readers looking for another option, I solved this using Node-RED. Under “manage palettes” I installed the node-red-contrib-hass package. It contains the hass-post node which calls the api/states API endpoint to set state on an entity in home assistant.

I’m also using a change node to set msg.payload to {"state": "off","attributes": {"assumed_state": true}} (or state could be “on”) and to set msg.entityid to switch.switch_name. Those values are passed into the hass-post node and the API is called as expected. Note that you don’t need multiple hass-post nodes. You could have multiple change nodes passing values into the same hass-post node (leave the Entity ID field blank in the hass-post node since that value comes from the change node).

Here’s a screenshot of my node red flow: https://imgur.com/a/dwpJwuS

Explanation: I have a z-wave plug that is also a power meter. Based on the wattage reported by the plug, I set the state on various switches that control my window evaporative cooler (via a Broadlink RM mini 3). This gives Home Assistant feedback as to what mode the cooler is operating in. So now I can change the fan or pump setting using the cooler’s IR remote and home assistant will know that I changed something. This also makes home assistant more fool-proof so it doesn’t get out of sync with the state of the cooler, which can happen if the IR signal from the Broadlink doesn’t get picked up by the cooler, for example.

7 Likes
31

that doesnt do what this topic is about, unless something hass changed in HA.

if you change a switch with API from on to off then HA sends the off command to the device.
you set the device to some state and then send a signal to HA to change it.
after that HA sends the change also, but you dont notice that.

your switch gets turned off twice, but for you thats no problem.
people who have toggle switches would have trouble with it.

32

If I go to the HA “States” page, I can change the state of a switch to “off”, but that doesn’t actually call the “turn_off” action on the switch, right? Isn’t that what this topic is about? If I use a curl command like this:

curl -X POST -H "Content-Type: application/json" -d "{\"state\": \"off\"}" http://HA_IP_ADDR:8123/api/states/switch.switch_name?api_password=PASSWORD

That will do the same thing, right? It changes the state, but I’m not seeing the switch action actually be called (my Broadlink mini doesn’t send an IR command to the cooler). I tried the same curl command with a z-wave light switch entity and it is changing the state of the entity does not turn the light on or off.

I’m on HA version 0.70.1. Are you on a different version that behaves differently?

33

in some cases it seems to do in others not.
but in many cases that just doesnt work.
if i use set_state in appdaemon (which is actually the same as you do) for a switch then it changes the state from the switch for a second and then it turns back. unless the state is changed for the component that is connected to it.

changing the state though api is just buggy. for sensors it works as it should, but for switches it was always buggy. at least for the switch types i own and can test.

34

Works for me. :slight_smile:

1 Like
35

for a lot of other cases also.
if i read back it also worked for others with set_state.

but it seems that you take an "unusual"path and thats why you need the set_state.
normally it would be:

something changes > automation (in HA, nodered or AD) gets triggered > HA changes something

you do

something changes > automation changes something and tells HA what has changed.

that takes out a functionality from HA and makes HA just a dashboard.
nothing wrong with that, but if you dont do that everywhere you could get lost when the amount of automations and settings get big.

and i dont see how it makes HA more foolproof, because if the IR command from the broadlink doesnt get picked up there is no trigger to change the states back. unless you check the states based on time. but if you do that, it isnt the set_state that makes it more foolproof, but your double check.

36

Did this work for your AC unit. I have the same problem. I have an input_boolean associated with Alexa and tied to automate my AC with the zxt-120.

It works fine but if I turn on with HA and then turn off with the remote then Asking Alexa to turn on no longer works because HA thinks it is on already.

I really just want a stateless switch, this is how I solved the same issue in SmartThings but it doesn’t seem to exist in HA.

I have tested if I set state using Curl to “NA” or anything other then on or off, after I issue the turn_on or turn_off then the next on or off will work.

I am just curious if you found a better way since it seems you had the exact same issue.

37

Yes it worked. However either the hass.io upgrade or switching over to unufi router has made it so ha gets invalid Auth error when i try this now.

38

OK thanks for reply. I guess you have not found a new solution? I wrote a script called stateless_switch which I call after issuing a turn_on or turn_off. It sets the state from on/off → “stateless”. It makes the UI get a little weird but I will hide the ui component anyway since it’s just for voice control. It’s working fine.

Did all /api calls stop working with hass.io or is it just changing state is no longer allowed? I hope they don’t remove this api feature. It’s the only good way I have found to hack around the issue.
I really don’t understand the point of “assumed_state”. It creates what looks like discreet on and off ui components but issuing a discreet request when the state is already set doesn’t fire triggers. So I don’t see how this is ever useful.

I see two ideal solutions for this. Both of which exist on the platform I am coming from.

  1. Add a force state change service. so instead of calling input_boolean.turn_on service you call input_boolean.turn_on_force_state_change or something better named.
  2. Alter assumed_state switches and input_booleans to always issue a state change when a discreet on or off is called. This was the intuitive behavior I was expecting. It just doesn’t work the way I would expect. If the UI state is “assumed” then why would you not issue the command to fire the device just because the state is the same as the existing state. The way it is now any incorrect “assumed” state causes the device to stop working.

Glad I found a hack for now. Hope it doesn’t get broken too soon :slight_smile:

39

the curl command above works.
but for some reason my rest_command api call stopped working.

40

you should add a door sensor to your aircon vent.
use that to update the state of the aircon when it is turned on / off via remote control.

1 Like