Rene Tode

ill see if i can reproduce it with these settings tonight. i guess it has to do with a change that andrew made, and ill see if i can find...

ok @pckeller29 i found out that there must have been a change in the entity structure. i tested it and got it working like this: copy the files from https://github.com/AppDaemon/appdaemon/tree/dev/appdaemon/widgets/baserss...

i dont think i had anything to do with it gettin better. this is just a bandage for what i think is an oversight from the changes from Andrew. but...

leave it open, so that Andrew knows that it should be corrected.

no sorry @daballiemo i dont know if Andrew just wants to change the widget or do something else. but Andrew isnt developing at the moment (because of real live) so...

i think thats because you use different options to do the same. in the yaml it should be: ``` global_modules: - fruit apple_app: module: apple_module class: AppleClass global_dependencies: - fruit...

test.yaml ``` global_modules: - fruit apple_app: module: apple_app class: AppleClass global_dependencies: - fruit ``` apple_app.py ``` import appdaemon.plugins.hass.hassapi as hass import fruit class AppleClass(hass.Hass): def initialize(self): self.log(f"AppleClass.initialize: Fruit.TEST_VAR = {fruit.Fruit.TEST_VAR}")...

thats obvious, and it would and could never work. the AppleClass is never reloaded. reloading the app means that the initialise function is reloaded. so the inheritance stays the same....

the global module is reloaded. and the app is reinitialised, and not reloaded when the global module changes. thats how it always worked and thats how its described in the...

its by the way probably causing breaking changes and a lot of trouble when that module would be reloaded instead of the app reinitialised. the app module could also contain...