Thanks for your work! This is awesome.
I only have one question, is it possible to disable the app discovery completely (included custom apps)?
Hi,
thank you for your feedback!
No itâs currently not possible to disable the app discovery completely. Do you have a use case where this is an actual problem? For me it never was an issue thus I havenât really thought about that. I think what could be done would be to disable auto discovery and only discover apps during a manually triggered scan. I would need to look into that too see if that requires a change in the binding code or just works out of the box: Thing Discovery | openHAB
Unfortunately the documentation does not clearly state how/where this configuration can be made 
Thanks for your quick reply! Actually this is not a big deal, I use custom apps for a few things like currently playing track, app is created via JS rule, every time I create a new one I need to ignore it in the things Discovery inbox so itâs just a small issue everything else works like a charm!
Hi, thank you for this great binding but i have a problem to display my custom apps with the native Time app. Every time the binding start the native app is hidden.
I need to manualy reboot the awtrix clock to show again the native Time app
Could you please show me how you create the app? I did not observe any similar problems so far
Nothing special, i add app by the inbox. these app display a scrolling text and i activate/desactivate apps by rule.
(When i disabled and enabled the bridge the native Time app is hidden)
And i have 2 strange behaviours 
-
in the inbox i have another Awtrix bridge but with another id
-
when i upgrade openhab i always need to reinstall the awtrix binding
perhaps i need to clear the openhab cache ?
Which binding version are you using or where did you get the binding from? The bridge with the different ID in your inbox tells me that you seem to be using the upcoming official version of the binding that will be available with OH5 but you still have the items created by the marketplace version. Could it be that you are using the prerelease version from my GitHub account? Please donât use that version is not ready for production (I should remove that from there)
I think youâre right. I migrated from OH4 to OH5 and didnât realise there was a binding built into the MQTT binding. I usually installed the version available on the STORE and persisted with the OH5 version. I had to recreate the THINGS and everything went back to normal (I hadnât seen a warning about this when I migrated, but I may have missed it). Thank you very much for your help and your explanations
Ok yeah thatâs explains your problems. I just mentioned that the official version is not compatible with the marketplace version in this thread but you may not have seen that of course. I had to change quite a few thing and channel Ids to comply with the OH coding standards to make this binding part of the official code base. On your end that means that you have to recreate your things, glad you figured that out already and got it working again!
Dear Thomas,
thanks for your great work creating this binding!
Just a simple feature request:
Please add the MQTT last will and testament feature to indicate online/offline status that was introduced in v0.98.
This would help for creating a rule to initialize the awtrix apps if the device was (re-)started.
The state âonlineâ or âofflineâ is available in the MQTT topic [PREFIX]/stats/device.
It could be added as a switch or the general channel status via âAvailability Topicâ like it is done for generic MQTT channels.
Thank you for your input, I agree that this would be a nice addition for the binding. I will have a look at that!
I implemented the LWT handling today but unfortunately it is not really reliable right now. The problem is that the LWT message is not sent as a retained message. Therefore I cannot get the online state unless the clock itself is restarted. So when you initialize your bridge thing when the clock is already running (e.g. due to a OH reboot or when you first create your bridge) you wonât know its online state until the clock is rebooted. @Udo_Hartmann already opened a ticket at the Awtrix 3 Repo: [ISSUE] LWT not showing up · Issue #707 · Blueforcer/awtrix3 · GitHub
If hope this will be changed. If not I think I will just assume that the device is online when the thing is created.
1 Like
EMQX has a rule engine that allows you to republish the incoming topic to a retained message:
However most users will probably run mosquitto which does not support this.
I just created a PR. The solution was rather simple: As long as the device is online it sends STATS messages on a regular basis. Once one of these messages is received the Thing comes online even when we had not received a LWT message up to then.
2 Likes
Dear Thomas,
thanks a lot for releasing this as a binding in OH 5.0!
If you have some time 
, it would be really nice to allow colored fragments in the text of an app. (Perhaps as an additional channel)
This would allow better text formatting, e.g. displaying temperature values in different colors like âTemp 10 °Câ in blue and âTemp 30 °Câ in red (rest of text in white).
Hi matmai,
Thank you for your suggestion. You are right, this is not yet possible. I know that the awtrix firmware supports this, however Iâm not entirely sure what would be the best way to achieve this with openHAB items. Of course we could simply use a text item with a certain formatting. Probably we could even use the existing text channel and maybe a switch to enable/disable interpretation of colour fragment information:
Example:
Text:
Temperature is <color=[255,0,0]>35 degrees</color>
Switch: Disable text formatting (Default: OFF)
I also think a switch is a good idea. Two different text channels would make it more complicated, as it would not be clear which one is being sent.
I would rather go for a valid html formatting because this could also be displayed directly elsewhere like on OH pages.
The text could also be produced with blockly:
Results in: Temperature is <font color="#cc33cc">35 degrees</font>
(Square brackets should also work instead of quotes)
Item text displayed in a widget:
The pseudo html was just a quick idea how it could be done in general. I havenât put any thought into the concrete syntax yet. I think it would be good to keep this as simple as possible since we canât support any other tags anyway. So maybe something like:
[#112233]This is[#cc3322] some multi-colored[#aabb55] text!
The switch would only be needed if one explicitly wanted to display the [#112233] part. But maybe we could also use some simple escape sequenceâŠ
HTML syntax would have the advantage that it could be reused elsewhere.
But I would also agree to a very simple syntax. Just keep in mind that there is already the color channel. I would expect the text should have this color if no other color is explicitly mentioned. So some kind of an end tag would be useful (to just color a single number in a longer string for example).
True that is an advantage. Makes more sense to use HTML than to come up with something completely new. Yes I think the color channel would be the default colour if no other colour is given by tags. I donât think that the gradient color can be used at the same time but the same goes for the rainbow colors.