Hi all,
Via Appdaemon using set_state() function to pass state back to HA, which works but gets overwritten when HA poles the sensor. Currently using sensor (which I know is wrong but good for testing purpose) - platform: command_line
Which sensor type should I use to ensure HA doesn’t overwrite the state with?
Is this the correct method to pass state information back to HA?
Thanks,
Rob.
Moved you into the proper category.
I believe that creating a template sensor and leave the template blank is the best way to do this. @ReneTode would have more details as I believe he does it a lot 
Thanks Andrew,
I’ll wait eagerly for his response!
Hi Rob, what did I do wrong here? 
Nothing wrong, it’s just that there is now a separate AppDaemon forum and the question would be more likely to be answered there. You had it in Third Party Integrations, which is more general.
(Worked though, right? )
Nothing done wrong, just me being a mod and trying to help. Sorry if I made you feel that way, certainly not my intention.
All good Rob, you certainly didn’t.
Just making sure I tow the line!
Rob.
i made a lot off sensors that i updated from appdaemon in the beginning.
but there were a few problems with it. (and i am still not sure if they were corrected right in later updates from appdaemon)
i worked my way around that in a way that HA likes.
i create files that i update.
so in the app i use:
sensorfile = open("/home/pi/.homeassistant/somesensor.py", 'w')
sensorfile.write("print(" + sensorvalue + ")")
sensorfile.close()
and in the HA yaml:
sensor:
- platform: command_line
name: some name
command: "python3 /home/pi/.homeassistant/somesensor.py"
HA automaticly updates the commandline sensor, but because you set the sensorvalue so that HA can read it it will always have the right value.
this way it is Always possible to override any sensor from HA.
lets say you have a temperature sensor bt you want it togive the value 0 for the first 5 mins from every hour.
then you let appdaemon put the value from the sensor in a file, but only for the time you want the updates to show, the other time you set it to 0.
then you create a new commandline sensor and hide the original.
A more secure way, which avoids the execution of potentially arbitrary python code in the somesensor.py file would be:
sensorfile = open("/home/pi/.homeassistant/somesensor.txt", 'w')
sensorfile.write(sensorvalue)
sensorfile.close()
and in the HA yaml:
sensor:
- platform: command_line
name: some name
command: "cat /home/pi/.homeassistant/somesensor.txt"
Otherwise it would be trivial for anyone with write access to the somesensor.py file to inject malicious code. This approach also removes the overhead of spawning a python interpreter for every sensor read.
All that said, I can’t help but think that anything requiring custom sensor logic wouldn’t be better implemented as a custom component/platform rather than within an app (I’m happy to hear of a use case that disproves this).
how will you create a sensor that tells you the last time an app is run through a custom component?
creating an app is way more easy then creating a custom component.
i have made 2 custom components and they are way to complicated for simple tasks.
even creating template sensors is most of the time so complex that its easier to make an app.
for instance a sensor that tells the max temp from the last hour or a sensor that tells the last time wind speed was over a specific value.
those sensors are created in a few lines with appdaemon.
the cat command can work, but not for everyone. i used my version on when i had HA running on windows.
its Obvious that you shouldnt give people that want to inject malicious code write access to your files.
HA and appdaemon is all about running py files, so if you worry about creating a py file, then dont run HA
saving overhead could be a decent reason why you could chose your way.
Well, yes, but giving an attacker who already has a hold in your system an avenue to attack another part of it is never good. For example if the attacker has access to a non privileged user account, which just happens to have write access to your somesensor.py file, then they can now execute code as the user running HASS, which could have more capabilities. In this case, you could lock down the file using unix permissions, but that’s still easy to screw up. Security is about defence in depth and limiting your attack surface.
Those examples seem mostly reasonable, but I would probably still implement them as template sensors, since it seems semantically cleaner to me. This is just personal preference, since I’m a bit of an architectural purist.
I think where appdaemon really shines is apps like Occusim, which provide complex features which would be really difficult to implement with a set of HASS automations/templates.
whats the difference between creating a py file for a sensor value or a py file for a custom component?
nothing in my eyes, both need the same security.
I think where appdaemon really shines is apps like Occusim, which provide complex features which would be really difficult to implement with a set of HASS automations/templates.
that also can be done with custom sensors, templates and/or automations.
but its like you say if its difficult the you use appdaemon.
almost every automation is easier in HA then in appdaemon. thats why i took them all out and made apps for them.
its like in achitecture, if i need to go to 2 doors to get to my kitchen when i use the frontdoor, i probably take the backdoor and i am directly in the kitchen.
is the frontdoor way more pure?
if i have the choice: do i create an app or do i create a custom component, i take the easiest way to reach my goal.
the goal is important, not the way i get there.
In your use case you are directly creating a .py file on the fly and then having HASS evaluate it. In the case of a custom component (and your app) you create that once and then can install it securely (i.e. only writable by root). Your somesensor.py file must be writable by (at least) the user running AppDaemon in order to work.
I personally find HASS automations great for simple things like turning on something when something else happens and apps better for more complex things.
I totally agree, I’m just a software engineer, so architecture is important to me!
i’m not, thats why i dont care 
but dont let it get in your way.
Your somesensor.py file must be writable by (at least) the user running AppDaemon in order to work.
if someone hass access to my appdaemonaccount he has acces to all that is important on my RPI anyway
at least he already has acces to all my apps, which are also py files
in my house i close my frontdoor, i dont lock up all doors to the livingroom, kitchen, bedroom, etc.
i knew a guy that drove to a store 1,5 hour away to buy a new hammer when his one broke. just because he had to get a few nails in the wall that day. the next day he had to go shopping next door to that store anyway.
he also could have used a stone, or any hard object to get those few nails in and save himself 3 hours driving and a lot of money.
not him, when i said that to him he said: a nail should be put in the wall with a hammer!
i guess we have said whats to be said about the subject. i wish you a good night
Security is always a trade off with convenience.
It’s the middle of the day here!
Rene’s system is so confusing that even he has trouble getting into it. I pity the hacker who tries. 
Would imagine Rene would have a couple of firewalls…
Anyway thanks guys, was thinking along the same lines.
Just hoping there would have been a smarter method.
Andrew, like your idea of the template sensor…have tried to create one but as per my standard skill level HA keeps spitting errors at me. so would be good if you could send through an example of blnk sensor template and can test it out pretty quickly.
Rob.
let the real rob stand up 
sometimes its hard to realize that others are at the middle of the day when its 2 AM here
on my network i am protected, but not overly.
my frontdoor is only closed when its cold outside, or when i am sleeping or away
a blank sensor template didnt work for me. (tried to make 1 in the past, couldnt get 1 to work)
Ha ha!
I bet you got heaps of windows! 
Reckon I’ve got another solution here…
Currently testing this out but using the command line sensor and set scan_interval: for a long period (not sure what the max length of time is ) to say 3600. When HA does execute the command line command, respond with something relevant or null.
AD class updates status every minute. So seeing a blank or whatever on HA sensor once an hour for 1 minute is no big deal.
Rob
@aimc, @ReneTode Here is another idea. How about a restful API interface to AD. That way HA could use the already existing restful api to query AD. AD could listen for a get, run a handler and pass back whatever it wants displayed in the sensor.
As long as you don’t have AD querying HA for a sensor that AD is supplying to HA through the API, it shouldn’t get to confusing.
Andrew already created an AD entity to use in the dashboards. (i think thats not released yet, but i am not sure about that)
i have no idea how he set that up.
but there wouldnt be a need for a restfull API if the set_state function was working like it should, in my eyes.
i rather do a run_every with a set_state, then that i need to create a sensor in HA and listen to a get from that.