Awtrix 3 Binding (formerly Awtrix Light)

Add-on Marketplace Bundles
, ,
54

A short test revealed this:

    Thing awtrixclock awtrix2 "Awtrix Schreibtisch" [
        appLockTimeout=10,
        discoverDefaultApps=false,
        basetopic="awtrix",
        lowBatteryThreshold=25
    ]

as child of an existing mqtt bridge. Channels are found by autoDiscovery (I did not check any further, but thing is indicated as online)

55

Hi, what actions are possible with this binding?
How can I check a binding for possible actions?
Greets.

56

Since I still haven’t found the time to write a documentation the easiest way would be to look at the code (if you are fine with that):

No guarantee that this works with all bindings though, they may have different package structures.

57

Thanks Udo!

58

Thanks for this.
I found some nice actions:
playSound(String melody)
showNotification(String message, String icon)
mabye this if I know how to use :smiley:
showCustomNotification(Map<String, Object> appParams, boolean hold, boolean wakeUp, boolean stack, String rtttl, String sound, boolean loopSound)

But I dont get these actions to work…
I’m working with RulesDSL, so my rule looks as follows:

var awtrixactions = getActions("mqtt.awtrixlight", "mqtt:awtrixclock:mqttbroker:Awtrixlight")
logInfo("awtrixactions", awtrixactions.toString)
awtrixactions.showNotification ("Test","52499")

neither showNotification nor playSound (with file, or with melody) works… I always get

The method showNotification(String, String) is undefined for the type ThingActions;

or

The method playSound(Object) is undefined for the type ThingActions;

Loginfo: org.openhab.binding.mqtt.awtrixlight.internal.action.AwtrixActions@434f4249

Can you help me?
Greets

59

I just found this thread:

It seems that I need to adapt my code so that actions will also work via DSL. I wasn’t aware of that but will look into it. Unfortunately I cannot give you an estimate when I will manage to do this. So long it might be an option to switch to js scripting, I gave an example for notifications in one of my previous posts.

60

Ok thanks. I’m staying at rulesDSL. I’ll create my own mqtt things for notifications and playSound.
Greets

61

Yes that’s another option that is easy enough to do :+1:

But don’t expect too much when it comes to sound. It’s pretty awful :sweat_smile:

62

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?

63

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 :man_shrugging:

64

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?

65

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:

  1. 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.
  2. 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 :frowning:

66

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…

67

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 :+1:

A rule is probably the best option you have right now

68

I have to re-test the mqtt persistence… :thinking:
Thx for the binding…
So I can delete all openhab persistence from the items?

69

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.

70

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 :grimacing:

71

the duration is available as channel in your binding… :upside_down_face:

duration
duration757×228 9.09 KB

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

72

Oh is it? :sweat_smile: it’s been a while I worked on this :joy:

Ok let me double check which property this was then… I think that I intentionally did not implement one of them in the binding :man_shrugging:

Ok I see… I did not implement the „repeat“ option. This was the one the behaved strangely, not the duration

73

I finally added support for DSL rules in version 1.1 if you are still interested