The GitHub issue I opened should have all you need. If not, let me know and I’ll get right on it.
Thanks. Issue resolved. New version in test. Please confirm if it works. Create a backup first this time 
@Fredrik_Palsson: My settings have survived the upgrade to 0.2.0 
I made one fixup to my commit for the latest translations, but since you haven’t merged them yet… should be good to go (re-synced with upstream).
@Fredrik_Palsson I upgraded last night and everything looked fine… but the app isn’t triggering any schedules. I turned the app off and on again (yip, not a restart) and I suspect it to work again. Just like last time.
I send a Homey diagnostic report: bb3654c6-a400-47cc-b990-dae908d14940
If I had to guess, I’d suspect the “restart” logic to have a bug.
Update 18:12:
A workday has passed and none of the events have triggered. Turning it off and on again (just now), had no effect, sadly.
So, just let me know what you need in order to debug it.
Update 18:17:
When adding the flow card and then selecting a schedule doesn’t work for me (either the ‘autocomplete’ has issues or the app isn’t running?)
Update 18:22:
The Homey timeline mentions that the app stopped working and that the developer has been notified…
Update 19:50:
Atleast for now, I’ll downgrade to the previous stable.
Something totally unrelated, any chance you will put the following on your to-do list?
I’d like to have a condition flow card to check if a schedule is active + an action flow card to activate/deactivate a schedule.
@Raeven: Really grateful for the reports. Have seen the crash reports. Have not had time to figure out whats wrong yet. I have a clue, though. Will report later.
I’d like to have a condition flow card to check if a schedule is active + an action flow card to activate/deactivate a schedule.
The second part of this is already on the to-do (change state of a schedule). The first part makes perfect sense in combination of cause. I will for sure add it to the to-do. Implementaition the upcoming week, I hope. But lets make 0.2.x stable first
So I think I have found the problem (if there are not multiple). As you are so kind and help my with reports and testing it is only fair I give you some of the details.
In version 0.1.x the object that contain the settings for the web parts in the settings was separated from the objects that contain the settings for the “running app”, the parts that trigger. As the Web UI progressed, so did the settings objects, and the got quite complex. As it is useful for the web UI to be able to walk up and down the settings tree there are references from the children to the parents. These are circular references. That works ok in the web part.
In version 0.2.x the object that contain the settings for the app has been copied to the “running app” to avoid maintaining two quite big chunks of code for reading, writing and manipulating settings when they do the same thing. This results in the “running app” having settings that has circular references. As Homey serializes the data passed between the app and the flow user interface (and other parts as well I guess) it ends up serializing data that has circular references and that means itt loops till it stops and crashes.
The solution is to create lightweight copies of the objects to pass to Homey when asked to. I believe this corrects the errors you have seen. The error reports show that the circular references are the problem, however not from where the problem originates. This means I cannot be certain the problems are solved, but I do believe it should be ok.
New version availiable in test soon. I hope you are willing to test in spite of all the problems.
Edit: I found another error when reading settings from 0.1.x version. This was the reason for the lack of triggering. This means I think I have found all the bugs you have reported.
1 Like
New version in test, correcting two bugs and also implementing trigger first of/last of.
Need Dutch and German translations. @DirkG, when you have time, and if you feel you want to, please look at the new translations for extended settings.
The GUI is getting “bloated”. If anyone have good suggestions on how to make it better, please let me know. The edit of schedule events if using advanced settings is the worst one…
1 Like
@Fredrik_Palsson: As far as the GUI is concerned, I know what you mean. That tends to happen as soon as (advanced) features are introduced.
Similarly for the textual summary of the event… when using more than one advanced setting, it tends te become ‘heavy’… but still gets the job done, I think.
(there are some first letter upper casing issues since strings are concatenated… which in Dutch is mostly incorrect where as for most German words it actually is correct 
)
If you are certain that all advanced settings are needed, then yes… we got our work cut out for us.
But lets make 0.2.x fully stable and translated first 
I have installed the new test version and will let it run during the course of the day. If anything happens, good or otherwise, I’ll keep you updated!
For now, let me just point you in the direction of my latest pull request:
Update 7:47:
Multiple scheduled events have occurred and my roller shutters have reacted accordingly. So, looking good!!
Update 15:52:
And yet more scheduled events were properly triggered (recently even). My schedules still work nicely!
Tonight I will change my schedules by using some of the advanced features (and test those tomorrow).
1 Like
@Raeven: Let me know the results, and I could push the latest version live after that if everything is ok.
Poll: What would you guys find more valueable?
- Adding flow cards for checking schedule state and flow cards for changing schedule state
- Adding functions for postponing an schedule event (involves additional flow cards of cause)
- Adding functions to skip the next upcoming schedule event, or skip upcoming events for X amount of time (also involves a few new flow cards).
- Adding monthly shedule.
- Add possibility to add “predefined” schedules with some basic templates of dimvalues and/or onoff events.
- Implement a visual representation of a schedule that is clickable to enter edit GUI.
- Duplicate schedules
You could copy the suggestions and repost with an order of your liking.
I guess my order would be:
Regarding the last idea (dim values and on/off events): that’s what I use the tags for. A flow uses a logic card to filter (e.g. the "action’ tag needs to be “open”) and performs that specific action.
This morning I edited my schedules to use several kinds of advanced settings during the day. If this evening the app, schedules and roller shutters behaved as intended: I’ll let you know!
I’d prefer to have another test version though, mostly because I want to check if the translations work properly (before releasing to stable).
Anyhoos: I’ll keep you posted
@Raeven: I appreciate your efforts!
The latest test version should contain all translations.
Looking forward to your findings.
@DirkG & @Raeven : Would you like to translate the below for the Readme?
Advanced features include:
- Random schedule event times. Example: trigger at random time between 21:00 and 22:30.
- Conditional triggering (only trigger schedule event if before or after certain time). Example: trigger at sunrise but only if before 06:00.
- First of/last of triggering (trigger the first or last of two trigger times). Example: Trigger first of sunrise and 07:00.
- All the features above can be mixed and combined as desired.
The translations are okay enough. But the problem stems from literal word-for-word translating English to Dutch (which isn’t always possible). I try to work around that problem, but especially the textual summary leaves to be desired as a result. Could I perhaps persuade you to use message ID’s instead of English texts somewhere in the near future? (e.g. “setting.advanced.firstof” or “event.summary.and”, if you catch my drift)
As said, the translations do their job. The schedules are triggered properly as expected and adding some advanced sprinkles on top didn’t mess anything up! (so, yay!!)
Only snag I hit was editing an event with the “first of / last of” advanced setting, which the GUI ‘forgot’ when editting… but I wasn’t able to close the dialog either. Ticking said advanced settings’ checkbox + the choosing the same type (e.g. “last off”), would show the settings I previously set (and allow me to close the dialog once again). The other advanced settings aren’t affected from what I could tell.
Somewhat related, I guess: when using the advanced settings “first of / last of”… isn’t it correct that when the main event is time-based that the advanced setting should be a sun event? Same goes the other way around. When the main event is a sun-event, shouldn’t the advanced (first of / last of) setting be time-based?
A “first of / last of” advanced setting with two time-based events or two sun events doesn’t make much sense (to me, anyway). What do you think?
Okay, here goes:
- Gebruik een tijdvak waarbinnen willekeurig een gebeurtenis plaats vindt. Bijvoorbeeld: trigger op een willekeurig tijdstip tussen 21:00 en 22:30 uur.
- Conditionele triggers (gebeurtenis alleen voor of na een bepaalde tijd). Bijvoorbeeld: trigger bij zonsopgang maar alleen indien eerder dan 06:00 uur.
- Trigger bij eerdere of latere gebeurtenis (trigger de eerdere of latere van twee gebeurtenissen). Bijvoorbeeld: trigger de eerdere gebeurtenis, bij zonsopgang of om 07:00 uur.
- Alle bovenstaande functies kunnen naar wens worden gecombineerd.
(this is me being lazy 
) If you want these translations in a pull-request… just let me know.
Thanks. Will implement message ID’s when I get some time to spare.
I will look at the scenario first of/last of when the dialog was not possible to close.
It would make sense to make sure that the first of/last of setting was solar when the main trigger is time based, and the other way around. The reasons for not implementing this are at least:
- The component to set a time (fixed or solar) is reused for every part (main trigger, random, condittional before/after and first/last of.
- What should the first/last of be if the main trigger is fixed and random span is solar? Logic could get messy.
- If more advanced settings are implemented, it might get even more complicated.
I will put it on the feature request list. 
Perfect. Thanks. Could you also translate the headline? “Advanced features include:”
As far as the “first of / last of” brainfart of mine is concerned, it’s not a big deal. The app works, you could argue that inputting garbage will ultimately only output garbage 
(perhaps something to tackle somewhere down the road when you have want to redesign / unclutter the GUI)
As for the translation, here you go:
Geavanceerde functies zijn onder andere:
1 Like
I see you pushed 0.2.5 to test! Since my (minor) bug is still present, let me clarify it a bit.
Steps to reproduce:
- Add a scheduled event using a solar event and which also makes use of the “first of / last of” advanced setting (set to “last of” and time “18:01”). Save and close the dialog.
- Save the settings and leave the app’s config.
- Open the app’s config page again.
- Go to the scheduled event and edit it.
Epected result:
- The event’s settings show to also use the “first of / last of” setting (“last of” and "18:01)
Actual result:
- The event’s setting only shows to be a solar event… advanced setting isn’t enabled, nor is the “first of / last of” setting. Without changing anything, the dialog will not close.
Translation
Zu den erweiterten Funktionen gehören:
– Zufällige Zeitplanereigniszeiten. Beispiel: Auslösung zu einer zufälligen Zeit zwischen 21:00 und 22:30.
– Bedingte Auslösung (Zeitplanereignis nur vor oder nach einer bestimmten Zeit auslösen). Beispiel: Auslösung bei Sonnenaufgang, jedoch nur vor 06:00 Uhr.
– Erster / letzter Auslöser (Auslösen des ersten oder letzten von zwei Auslösezeiten). Beispiel: Zuerst bei Sonnenaufgang und dann um 07:00 Uhr auslösen.
– Alle oben genannten Funktionen können beliebig gemischt und kombiniert werden.
1 Like
I see you pushed 0.2.5 to test! Since my (minor) bug is still present, let me clarify it a bit.
I do believe it is fixed now in 0.2.6 (test). Try it out if you dare
