@aimc how is the feeling about going out of beta for 3.0? I want to move my automations over to my new machine but I don’t want to run too much beta since its such a vital piece of code
the step from beta to not beta is just a trivial point in time.
if you trust it (and andrew) as it is at the moment (hardly any issues) then you can move
3 Likes
Okay, so maybe it was a cache issue, as it just started working for some reason. I really didn’t do anything different, just left the dashboards closed for a while and now it does appear to be working. Sorry for the run around.
you didnt close the dashboards before, before restarting appdaemon.
thats why i have created that list in that order.
the reason why i know it wasnt closed is that the dashboard was connecting 0.3 seconds after Appdaemon was completing startup.
but im glad its working now.
Actually, I had followed your steps in order (except for clearing the sub directory that i couldn’t find) the log I sent was after a second restart of AD once the dashboards were back open (thought that might have some impact), so yes at that point they would have connected quickly, but the first attempt did follow your steps. This time, I just left the dashboards closed for about 30 mins or more. I do use FullyKiosk Browser, so perhaps it was related to that.
I am explicitly not doing that.
Add-on upgrades are not subjected to AppDaemon versions alone.
Secondly, I follow semantic versioning for all my add-ons.
Third, I like consistency across all my add-ons.
hmm, yeah with fully you need to close fully and the device also to clear the cash completely or do it in the fully menu.
but in that case you missed the last point (open 1 dashboard in google chrome) 
no harm done, but if you want people to help you debug something, its important to do exactly as asked or mention that you do it different. (i cant see from here that you are using fully when you dont tell me)
@frenck you could also change this line in the log:
Python Apps and HADashboard using AppDaemon 3.x for Home Assistant
to
Python Apps and HADashboard using AppDaemon version 3.0b5 created by Andrew Cockburn.
in that case everyone know instantly which ad version they use.
That adds a manual dependency to the documentation, which is not part of the release management / devops / CI/CD system. So no.
This that are manual, tent do be forgotten.
Thanks again and just for the record, I did follow ALL the steps, including trying a single dashboard in chrome (even used a pc I don’t ever use to make sure it was a fresh test) and did use the menu in Fully to clear the cache then close them out. Just want to make sure you know I was following directions 
Good point about providing more detail on use case, will do that next time. Thanks again for the help clearing it up.
1 Like
you need to create the update manually.
the first line needs to come from somewhere, so it is editable.
its not that you cant, but it seems you dont want to.
off course i can be wrong, so please tell me what you CAN do to make it more clear to people which version from AD they have installed?
so that people like me helping the community have less trouble finding out what AD version is used.
Cash 
solves a lot of problems 
1 Like
Yep, I don’t want to edit files manually in a release process.
There are multiple ways to find out.
- Commit history
- Dockerfile
- Changelog
- Release notes on the forums
- GitHub Release notes / history
- Add-on log (in Hass.io)
@frenck I agree with you that add-on versioning should not be tightly linked to the version of the included components, they can evolve independently and the add-on developer must be free to choose its version numbering to reflect that.
That’s why the best I could think of is the two-part versioning. That is allowed in Semantic Versioning (see https://semver.org/#spec-item-9 ) for pre-release versioning and for build metadata, with a bit of flexibility I think it is applicable to our use case.
I agree with @ReneTode that it will make things a bit easier here in the forum.
That said, your addon is your kingdom, I hope you don’t feel bad for us going against your choices…
1 Like
@namadori I don’t feel bad… I like consistency across the board.
For example, the Homebridge add-on consists of 2 major components. Homebridge and the Home Assistant Homebridge plugin. v0.3.0-HB0.4.8-HBHAP1.3.6? Don’t get me started on Pi-Hole (3 components).
So, I’ll just keep it simple.
so you expect me to keep a file up to date whith which version of your addons do compare to which versions of AD?
I want people to be aware of what appdaemon version they use.
that way they also use the right documentation.
and we wouldnt get the question every time like:
“how can i find out which version of AD i use? i use addon version …”
i though hassio was there to make it easy for people. would be nice if it also was making it easy for the people helping the people who use hassio.
@ReneTode Good point!
Still not going to change it. But thank you guys for the suggestion.
I’ve made my point clear on the why I do this and still stand with my decision on this.
Can we think of a better way to show in plugins additional info about the components they are using?
From my point of view, what’s most annoying is that to check which version of (for example) AD I am using, I must restart the addon. Once the first part of the log is flushed away, afaik there’s no other way.
The same is true for example for the Mosquitto addon.
Even worst for the Nginx plugin, that says “starting version 3.2.2” when Nginx is currently at version 1.13.
If we can think of a good, not manual, way of showing this info in the plugin page, maybe it will be added to Hassio.
This is going offtopic. Nevertheless, there are many many factors… Like ok, the app daemon addon, ever wondered what python version it is running? Let’s not go there…
Like ok, the app daemon addon, ever wondered what python version it is running? Let’s not go there…
yeah but please lets go there.
we always ask people which python version is running, because it is important for the program, the apps and how people use it, and why they get errors.
there is nothing wrong with providing people with IMPORTANT info that they NEED to debug.
Hey Andrew,
Just noticed in this version of the beta, I’m getting the below in my log file at start up.
2018-03-08 18:29:44.062676 INFO AppDaemon: Initializing app livingroom_lights using class LivingRoomLights from module livingroom_lights
2018-03-08 18:29:44.063283 WARNING AppDaemon: ------------------------------------------------------------
2018-03-08 18:29:44.063467 WARNING AppDaemon: Unexpected error running initialize() for livingroom_lights
2018-03-08 18:29:44.063737 WARNING AppDaemon: ------------------------------------------------------------
2018-03-08 18:29:44.067117 WARNING AppDaemon: Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 1495, in init_object
init()
File "/conf/apps/livingroom_lights.py", line 21, in initialize
self.run_at_sunrise(self.morning_off, offset=3600, constrain_input_select='input_select.house,Morning')
File "/usr/local/lib/python3.6/site-packages/appdaemon/appapi.py", line 428, in run_at_sunrise
handle = self._schedule_sun(name, "next_rising", callback, **kwargs)
File "/usr/local/lib/python3.6/site-packages/appdaemon/appapi.py", line 406, in _schedule_sun
event = self.calc_sun(type_)
File "/usr/local/lib/python3.6/site-packages/appdaemon/appapi.py", line 247, in calc_sun
return self.AD.calc_sun(type_)
File "/usr/local/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 825, in calc_sun
return self.sun[type_].timestamp()
KeyError: 'next_rising'
This only occurs on a restart of AppDaemon, it doesn’t seem to display the same error if I edit the app and let it reload (any minor edit).
If I comment out the corresponding line, it presents the same error for the next initialise line which is:
self.run_at_sunset(self.evening, offset=-7200, constrain_input_select='input_select.house,Home') - the only change being that the KeyError is for ‘next_setting’
This is using your docker container.
Thanks as always for all your work on AD!