updated the examples to be usable with appdaemon 3.0 (#7784)

the examples where still written for AD 2.0
there have been breaking changes from 2.0 to 3.0

source/_docs/ecosystem/appdaemon.markdown

@@ -35,9 +35,9 @@ The best way to show what AppDaemon does is through a few simple examples.
 Let's start with a simple App to turn a light on every night at sunset and off every morning at sunrise. Every App when first started will have its `initialize()` function called, which gives it a chance to register a callback for AppDaemons's scheduler for a specific time. In this case, we are using `run_at_sunrise()` and `run_at_sunset()` to register two separate callbacks. The argument `0` is the number of seconds offset from sunrise or sunset and can be negative or positive. For complex intervals, it can be convenient to use Python's `datetime.timedelta` class for calculations. When sunrise or sunset occurs, the appropriate callback function, `sunrise_cb()` or `sunset_cb()`, is called, which then makes a call to Home Assistant to turn the porch light on or off by activating a scene. The variables `args["on_scene"]` and `args["off_scene"]` are passed through from the configuration of this particular App, and the same code could be reused to activate completely different scenes in a different version of the App.
 
 ```python
-import appdaemon.appapi as appapi
+import appdaemon.plugins.hass.hassapi as hass
 
-class OutsideLights(appapi.AppDaemon):
+class OutsideLights(hass.Hass):
 
   def initialize(self):
     self.run_at_sunrise(self.sunrise_cb)
@@ -58,9 +58,9 @@ This is also fairly easy to achieve with Home Assistant automations, but we are
 Our next example is to turn on a light when motion is detected and it is dark, and turn it off after a period of time. This time, the `initialize()` function registers a callback on a state change (of the motion sensor) rather than a specific time. We tell AppDaemon that we are only interested in state changes where the motion detector comes on by adding an additional parameter to the callback registration - `new = "on"`. When the motion is detected, the callback function `motion()` is called, and we check whether or not the sun has set using a built-in convenience function: `sun_down()`. Next, we turn the light on with `turn_on()`, then set a timer using `run_in()` to turn the light off after 60 seconds, which is another call to the scheduler to execute in a set time from now, which results in `AppDaemon` calling `light_off()` 60 seconds later using the `turn_off()` call to actually turn the light off. This is still pretty simple in code terms:
 
 ```python
-import appdaemon.appapi as appapi
+import appdaemon.plugins.hass.hassapi as hass
 
-class FlashyMotionLights(appapi.AppDaemon):
+class FlashyMotionLights(hass.Hass):
 
   def initialize(self):
     self.listen_state(self.motion, "binary_sensor.drive", new = "on")
@@ -79,9 +79,9 @@ This is starting to get a little more complex in Home Assistant automations, req
 Now let's extend this with a somewhat artificial example to show something that is simple in AppDaemon but very difficult if not impossible using automations. Let's warn someone inside the house that there has been motion outside by flashing a lamp on and off ten times. We are reacting to the motion as before by turning on the light and setting a timer to turn it off again, but in addition, we set a 1-second timer to run `flash_warning()`, which, when called, toggles the inside light and sets another timer to call itself a second later. To avoid re-triggering forever, it keeps a count of how many times it has been activated and bails out after ten iterations.
 
 ```python
-import appdaemon.appapi as appapi
+import appdaemon.plugins.hass.hassapi as hass
 
-class MotionLights(appapi.AppDaemon):
+class MotionLights(hass.Hass):
 
   def initialize(self):
     self.listen_state(self.motion, "binary_sensor.drive", new = "on")