Yes that’s another option that is easy enough to do 
But don’t expect too much when it comes to sound. It’s pretty awful 
If you want to remove the app completely from within OH you can set the app to inactive (via a switch linked to the channel) before you delete the thing.
I did that and it seems to work, but the unwanted apps re-appear after OH restart. I helped myself by adding a POST request that removes the apps using the Awtrix HTTP API on OH startup, but that is more of a workaround. Any idea on why this happens?
Have you removed the thing after deactivating it?
I think that the binding cannot detect that the app should be deactivated as it cannot query for the state of the connected switch item. It might work if you use a persistence provider for the switch item so that the state is restored at startup but I haven’t tried that yet. I’m not sure if this triggers a command to the thing channel 
I want to ask about startup restore.
I have my items in my restore on startup group but it doesn’t work.
My disabled apps were enabled and the items were at default values…
Is the persistence restore on startup working for you?
Greets
Edit:
I think only the disabled apps were resettet… Could this be?
Yes this could be the case. Let me try to explain what is going on there:
For active apps you do not need to restore values from OH persistence at startup because the items are initialised by the last retained mqtt message that was sent to your broker.
For disabled apps this is quite different: While the active channel seems to be just another channel it behaves quite differently compared to the other channels: when you disable an app the retained mqtt message is deleted and thus the persistent storage of the app is removed. When you restart OH in this state there is no retained message available to restore the app state. Currently the binding initialises the app (and the linked items) with the default values just if you would have just created a new app from the OH UI. This is of course not the desired behaviour in your case.
I think however that it might be difficult to really solve this issue because:
- As far as I know OH would not send a command to an item when it is restored at startup. Therefore the underlying binding does not know the state of the linked items and there is no API to access the items states. This is just a general OH concept that makes a lot of sense in general but prevents the binding from picking up these item state updates.
- I could change the binding so that the item states are not initialised with their defaults on startup but this would lead to another problem: the binding keeps an in-memory representation of all the latest item states of an app. This is necessary because it needs to resend the complete app configuration to the clock every time an item receives a command and not just the last changed item value. BUT: if the items are not initialised the binding internal representation will not be in sync with the item states… this would lead to funny behaviour because if e.g. you change the text item of your OH App you would still see all the default values on the clock with only the latest text change…
I haven’t found a good solution for that problem. The fact is that you should not have any deactivated apps while rebooting OH unless me or anyone else comes up with a brilliant idea on how to solve this situation 
Hmm okay…
That means the retained messages are not lost if the mqtt broker is restarted?
my mqtt broker is on the same machine than openhab and the active apps were not resetted after reboot of the hole machine.
I think I’ll start a rule after restart to send initial commands to the disabled apps…
Greets…
If you have a persistent storage configured for your mqtt broker the messages are restored after startup. Since your apps reappeared everything seems to be setup correctly
A rule is probably the best option you have right now
I have to re-test the mqtt persistence… 
Thx for the binding…
So I can delete all openhab persistence from the items?
I’m not 100% sure about the timing but I read somewhere that the item states are restored before the things are initialised. If this is the case then it should not make any difference: the binding will just overwrite the restored items. Since the states should be the same you would not notice this unless you look in the event log.
Hmmm I just came up with a completely different idea but I need to try this before I know if this could be a solution:
Awtrix light offers an option to define the duration an app is shown. I do not support this option in the binding because it has some nasty side effects. For example when a short text is repeated only once and the duration is longer you get a black screen for the remaining time or the text might not even repeat once when the duration is too short.
To cut a long a story short I will try to set the duration to 0 instead of removing the retained message completely from the broker when the app is set to not active. If the clock interprets this as “don’t show the app at all” everything will be fine because then there still is a persistent message to restore from after reboot.
However if I remember correctly the clock does never forget when the duration has been set. This would mean that I could not simply omit the duration in the next message to reset to the default behaviour but would have to explicitly set a duration which again leads to the unwanted side effects. However the dev of the firmware might be open to a proposal to change this (for other options it is enough to send an invalid value to reset the previous selection). If not the binding could also remove the app and instantly recreate it without a duration. So I see a potential way forward. But first I need to check what the effect of a 0 duration is 
the duration is available as channel in your binding… 
I tried if I set to 0s it is shown with the default duration.
If I set to 4s its shown for 4 seconds.
Greets
Oh is it? it’s been a while I worked on this 
Ok let me double check which property this was then… I think that I intentionally did not implement one of them in the binding
Ok I see… I did not implement the „repeat“ option. This was the one the behaved strangely, not the duration
I finally added support for DSL rules in version 1.1 if you are still interested
Hi DrRSatzteil, I just tried to install the binding on my OH4.1.2 build. Is it really tested under version 4.1.X? I have issues to install it via the add-on marketplace. Unfortunately I got no error message except: “failed to install marketplace:XXXX”
The marketplace install does not work unfortunately. However I have no idea what the problem is you would need to download and install it manually (put it in your addon folder) until somebody can help me here to fix this. I use the binding in my 4.1.X instance so this is just an installation issue.
Hi Sebastian,
with the latest Awtrix 3 versions some new app properties were introduced. There is one that might solve the reboot issue we discussed before:
The new lifetime channel tells the clock to remove an app after a certain period of time in seconds. So instead of removing the app completely from the mqtt broker you may now just set the lifetime to one second instead (0 means ignore lifetime setting so 1 would be the lowest value). The clock will forget the app after this second until your OH instance sends a new version of the app. The last app version will however will remain on the broker and OH will use this data to initialize the items after a reboot. You might want to check that out to see if that works for you!
When you reboot the clock your “inactive” apps will be shown for a second but then will disappear again. The same goes for an OH reboot.
Thx, I’ll have a look at this.
Greets
I created an app to display the current solar production and battery state today. My other apps use pretty much the same patterns so I thought it might be of use for somebody if I shared this with you.
Here is a preview of the finished app:
The current power is shown as text and styled as needed by the rule. The progress bar represents the battery state and changes its color from green to red when its nearing 0%.
You will find the complete configuration at the end of this post.
The general idea behind this design is that the app is basically represented by a single rule (+ the necessary items) that gets triggered whenever something relevant happens and updates all the items of the app where needed (though this could also just be a cron trigger). This implies that you usually don’t have to worry too much about the item state at OH startup or persistence in general. The state of the items does not really matter as long as the app is not shown and when it is shown the rule makes sure that all items have the correct state.
A few other things worth mentioning:
- The lifetime of the app is determined by the rule condition: The app will only be sent to the clock as long as a given condition is true. In this case only as long as the solar panels produce at least a little bit of energy. This might not be necessary for every app. You could also just rely on 2.
- To disable the app when the condition is no longer true the rule sets the app lifetime to the desired timeout. As soon as the rule condition is no longer true the app will timeout and will disappear from the clock after that. If you don’t use a condition as described in 1. the app will simply timeout if no items changed for the specified time. If you want to display information that should not disappear use a notification instead!
- I always use “sendCommandIfDifferent” for all items in order to not spam the logs with unecessary commands. You still might want to use a “sendCommand” for at least one item to make sure that the app does not timeout even if no item states changed in a certain time period.
configuration: {}
triggers:
- id: "1"
configuration:
itemName: Adresse258_Umrechnung
type: core.ItemStateChangeTrigger
- id: "2"
configuration:
itemName: Solarleistung_Umrechnung
type: core.ItemStateChangeTrigger
conditions:
- inputs: {}
id: "4"
configuration:
itemName: Solarleistung_Umrechnung
state: "0"
operator: ">"
type: core.ItemStateCondition
actions:
- inputs: {}
id: "3"
configuration:
type: application/javascript
script: >+
var { HSBType, DecimalType, PercentType } = require("@runtime");
var battery = parseInt(items.getItem("Adresse258_Umrechnung").state);
var power = parseInt(items.getItem("Solarleistung_Umrechnung").state);
var hue = Math.round((battery / 100) * 120);
var hsb = new HSBType(new DecimalType(hue), new PercentType(100), new PercentType(50))
if (power >= 1000) {
power = (power / 1000).toFixed(1) + " kW"
} else {
power = power + " W"
}
items.getItem("Awtrix_PV_App_Icon").sendCommandIfDifferent("Sunbattery");
items.getItem("Awtrix_PV_App_Progress_Bar").sendCommandIfDifferent(battery);
items.getItem("Awtrix_PV_App_Progress_Bar_Color").sendCommandIfDifferent(hsb);
items.getItem("Awtrix_PV_App_Display_Text").sendCommandIfDifferent(power);
items.getItem("Awtrix_PV_App_Text_Case").sendCommandIfDifferent(2);
items.getItem("Awtrix_PV_App_Lifetime").sendCommandIfDifferent(30);
type: script.ScriptAction