AppDaemon Q&A

Third party integrations AppDaemon
602

i dont have Alexa, i think we will get google home in the future, but…
my wife gets annoyed enough that i speak to myself :wink:

1 Like
603

quick question, in the examples it always has “import appdaemon.appapi as appapi”
but in the API guide it has “import homeassistant.appapi as appapi”

Which is the correct one or do they both work?

604

the first (example) ones work.

605

Then I should put in a change for that file?

606

if you mean a change for the API then yeah :wink:

607

submitted a request to change the few places in the API.md that reference homeassistant.appapi

608

Thanks very much :slight_smile:

609

I’m trying to get the time passed since the last update of a sensor with the following code:
lsensor_time_since_updated = self.datetime() - self.convert_utc(self.get_state(self.light_sensor, "last_updated"))

Unfortunately, convert_utc seems to fail with:
lsensor_time_since_updated = self.datetime() - self.convert_utc(self.get_state(self.light_sensor, "last_updated"))

Any tips?

610

self.get_state(self.light_sensor, “last_updated”) gives probably a string.
and self.convert_utc() could need a time

i think you should look in that direction.

(didnt look anything up right now, API could tell you more)

611

Nope, the api says that the parameter is a string :-\

612

try self.log(self.get_state(self.light_sensor, “last_updated”) )
and see if in the log you get
An ISO 8601 encoded date and time string in the following format: 2016-07-13T14:24:02.040658-04:00

if not then thats the problem.

613

I am trying to handle weather underground alerts and I was not sure how such can be implemented when dealing with attributes and which are not guaranteed to exist all the time. Some more discussion is going on here in this thread

alias: "Weather Warning Tornado"
trigger:
  - platform: numeric_state
    entity_id: sensor.pws_alerts
    above: 1
condition:
   condition: or
   conditions:
     - condition: template
       value_template: '{{ states.sensor.pws_alerts.attributes.Description == "Tornado Warning" }}'
     - condition: template
       value_template: '{{ states.sensor.pws_alerts.attributes.Description_TOR == "Tornado Warning" }}'
action:
  service: script.weather_warning_tornado
1 Like
614

I’d be interested to see how you do this as it seems a better use case for AD than for traditional automation because of all the different alert condition types.

615

Let me know if you need help. I’ve been playing in AD lately with Weather Underground’s forecast data so I’m in the neighborhood so to speak.

1 Like
616

@turboc, thanks for the offer, let see how much good I can describe what I need.

I have AppDaemon app that listen to change on Weather Underground alert changes but want to filter those alerts to most critical one like tornado, hail etc but not like fog advisory as I have audio announcement using Google cast devices and definitely do not want to wake middle of the night just for fog alert but would like to for tornado.

sensor.pws_alerts is just number of active alerts but in order to get type of alerts looks like we need to check attributes but depending on the number of active alert the attribute(s) formulated differently as mentioned in the other discussion thread.

My goal is to notify via audio and text notifications on certain types of alerts but not all, I have notification code/app working but trying to figure out (need help) how to identify specific alerts which I am interested in. May be in future Weather Underground component alert sensor will have better way to see the alert types.

May be I can use hasattr() function to check presence of each possible values like Description_TOR, Description_SEW?

Thanks all

1 Like
617

something like this?

tornadowarning = ""
your_sensor =
your_attribute =
try:
  tornadowarning = self.get_state(your_sensor,your_atrribute)
except:
  self.log("tornado attribute doesnt exist")
if tornadowarning != "":
  notify me

as callback from a run_every

1 Like
618

I’m guessing you are using the API as described on this page

https://www.wunderground.com/weather/api/d/docs?d=data/alerts#city_within_the_usa

619

Nice, this should work. I will have few of this kind of try/except to check the alerts I am interested and go on from there.

I will be putting this code under state change event so I will not have to call using run_every() function for efficiency.

Let me work on this changes this week-end and once working/tested, I will post code here so it can benefit some else too.
Thanks @ReneTode

1 Like
620

Side topic here. This is another example where I wish I had a scroller or something where alerts like this could be scrolled across the HA screen. Like a scrolling persistent notification.

621

changing the frontend is not really my thing :wink:
but i can think of ways to get a scrolling notification in dashboard :wink:

@scadaguru your welcome.