openHAB openHASP integration

[MickPo]

Hi there,

I expect I am in a minority as an openHAB user of openHASP and that the approach to using openHASP might be quite different if I were using the Home Assistant integration.

I love the potential of this project and have acquired 10 or so Sunton ESP32-2432S028R screen jobbies with the view to placing one of these units above each of the light switches in my home each with a default screen representing at least the control options available at the switch and the ability to swipe left or right to access other screens.

All plates are configured with exactly the same screens but defaulted to the screen designed for their position. Some switches are represented on multiple screens depending upon where the screen is positioned.

Integrating a plate currently involves a lot of configuration in OpenHAB. This includes:

• An MQTT "thing" with over 50 "channels"

• Corresponding "item" objects for each of the "channels"

• A (very long) rule which fires on change of any of the controlled items and updates the state of the corresponding MQTT "channel" to match.

• A rule which fires on change of each of the MQTT "channels" and updates the corresponding openHAB "items"

• A rule which fires when a plate comes online and updates each of the MQTT devices so that they are synchronised with the same state.

NB: I may be able to simplify this last rule after seeing that there is a synch option available.

Reproducing the above configuration for each device would be problematic for many reasons and the most elegant option is to configure each of the plates to subscribe to the same MQTT topics. This is how MQTT is designed to work, and it does work very effectively ensuring that each of the ten plates is updated with every change and stays perfectly in synch with changes on one unit instantly reflected each of the others.

NB: This is now easy to configure with the most recent firmware. Previously it was necessary to use the same name for every plate which mostly worked but was confusing.

I am however unable to find a way to configure MQTT in openHASP so that the command and state information for on screen objects like hasp/foo/state/p12b1 and hasp/foo/command/p12b1.val all go to the same path like hasp/foo but other stat messages related to the individual plate like hasp/foo/command/backlight, hasp/foo/state/idle or hasp/foo/state/input22 to be directed to an individual topic.

Hopefully I'm missing some option which would allow me to differentiate between differently scoped properties. The additional options in firmware 0.7.0 MQTT configuration seems to have improved things in that I can specify the same Node Topic rather than having to use the same plate name for all plates which is a huge improvement.

The documentation for 0.7.0 doesn't seem to detail any of the new MQTT settings. Monitoring the output with mqtt-spy doesn't indicate that there is an option to differentiate plate specific changes such as idle state by sending them to a plate specific topic.

On a related matter, I have purchased IR sensors for the purpose of waking the screen of each plate when there presence is detected near them. The state of these sensors is available under hasp/foo/state/input22 which doesn't allow me to tell which device to wake up in response to presence being detected. The best I could manage seems to be to wake all screens in response. If there is a way to respond locally via cmd files (or something) to the IR input, that would also solve my problem.

If there is not currently a way to differentiate MQTT messages which are specific to the operation of each plate (as opposed to the status of objects on pages) by sending them to a plate specific topic, then adding this option would make it much easier to achieve certain things such as controlling the screen brightness based on a presence sensor. Another option might be to add additional properties to the events to indicate the node name they have been sent from.

Overall, it has required a lot of work to generate the objects and scripting required to maintain synchronisation between plate switches etc and the things in openHab which they represent. I think it would be much easier to integrate openHASP into openHAB, and probably other platforms, if it were possible to add MQTT definitions to each of the objects in the pages.jsonl file.

openHAB supports the option of publishing all internal states to MQTT for read/write access to everything in openHAB. Being able to connect openHASP objects directly to these MQTT topics would simplify integration a great deal. I imagine it would be necessary to define both the MQTT topic to link to and a transform or mapping for the values something like (1 = "ON", 2 = "OFF") or (1 = "HEAT", 2 = "DRY", 3 = "FAN", 4 = "COOL") for each of the pages.jsonl objects. I guess lvgl might not make this as easy to implement as I imagine so something like a mqttmappings.json file describing overrides for the default MQTT topics and mappings would work equally well.

Thanks for all of the effort that obviously goes into openHASP. It's an excellent project and I'm excited to be adding openHASP to my home. I appreciate any advice that you might be able to offer and understand that there are always tradeoffs when selecting which features to add to a project.

Cheers,

Mick.

[fvanroie]

I don't know openHAB, but can't you subscribe to hasp/#/state/ topic?
It seems like this is something a Home Automation System should be able to handle...
There is no way in openHASP to separate these messages to different topics.

I imagine it would be necessary to define both the MQTT topic to link to and a transform or mapping for the values something like (1 = "ON", 2 = "OFF") or (1 = "HEAT", 2 = "DRY", 3 = "FAN", 4 = "COOL") for each of the pages.jsonl objects

I really think this is backwards. The Home Automation System should handle the topics and mappings for the devices and not the other way around.

[MickPo]

Thanks for getting back to me fvanroie. I'm not sure if I understand what you're saying by "... but can't you subscribe to hasp/#/state/ topic?" above. MQTT-spy doesn't allow me to enter a wildcard in this way and the MQTT spec says that this is not a valid filter.

https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

4.7.1.2 Multi-level wildcard
The number sign (‘#’ U+0023) is a wildcard character that matches any number of levels within a topic. The multi-level wildcard represents the parent and any number of child levels. The multi-level wildcard character MUST be specified either on its own or following a topic level separator. In either case it MUST be the last character specified in the Topic Filter [MQTT-4.7.1-2].

Non normative comment

For example, if a Client subscribes to “sport/tennis/player1/#”, it would receive messages published using these topic names:

· “sport/tennis/player1”
· “sport/tennis/player1/ranking”
· “sport/tennis/player1/score/wimbledon”

Non normative comment

· “sport/#” also matches the singular “sport”, since # includes the parent level.
· “#” is valid and will receive every Application Message
· “sport/tennis/#” is valid
· “sport/tennis#” is not valid
· “sport/tennis/#/ranking” is not valid

When I attempt to implement the suggested wildcard configuration in openHAB I receive the following error in the logs:

Similarly MQTT-Spy shows this message:

Is hasp/#/state a topic you think I should be able to subscribe to or are you just suggesting that I should reproduce the configuration above for each of the openHASP plates that I install? This would not be practical to maintain for multiple plates, at least without me getting smarter about how this is done.

I've tested running ten plates all subscribing to the same topics and they each work surprisingly well, all staying synchronised when the state of an object is modified either within openHAB, at a physical light switch or via one of the plates.

I think that there is a potential difference in the role of openHASP plates (or at least the use that I am trying to put them to) from most MQTT devices in a home in that they are control surfaces for other devices. Rather than being a device such as, say, an MQTT connected light switch which only needs to be concerned with its own specific state, openHASP plates are controlling the state of external devices already present on another system. As such they need to be able to communicate changes in their own state when someone turns on a button so that the subscribing system such as openHAB or perhaps another MQTT device directly can turn on the light (or whatever). As this state can also be changed externally, by flicking a physical light switch, switching the device on in HABpanel, having an automation turn on the light because someone has arrived home etc, it also needs to maintain state based on the state of the object (or be updated by the external system) for a potentially large number of devices. In this way I think openHASP is more like a home automation system than a light switch.

I believe that adding a relatively small amount of (optional non-breaking) configuration information to openHASP by allowing objects on hasp plates to target specific topics on the MQTT message bus could vastly reduce the complexity and effort for the end user implementing openHASP devices. The multiple screens of configuration in the post above would be reduced to a few (well, 50 or so I suppose) entries matching openHASP objects to topics and basic transformations.

Looking at the instructions for integrating with Home Assistant there still seems to be a degree of faffing about required to set things up and that's with a helper add-in which has to be maintained. I'm not that familiar with Home Assistant or how it does things. A quick google shows MQTT Eventstream and MQTT State Stream as possible equivalents to the openHAB MQTT Event Bus? IDK. Perhaps there are other options or there's no point because Home Assistant integration is easy just the way it is.

Irrespective of the above discussion WRT per openHASP object MQTT configuration options, openHASP is working well with openHAB the way that I have it configured. I was quite impressed with how easy it was to just plug in my IR presence sensors, configure the GPIO settings and have the status reflected immediately in MQTT. It would be great if there was a way to have each plate turn on its screen whenever someone approaches it. I think this would make the plates much more user friendly and intuitive, particularly for guests who I just know are likely to hit buttons accidentally while trying to wake the device.

Thanks again for all of the work that you put into openHASP. It's a fantastic solution especially compared to Nextion options that I had been considering before discovering openHASP.

Cheers,

Mick.

[fvanroie]

I mixed up multi-level and single-level wildcards. Try hasp/# or hasp/+/state/#, depending on your use-case...
As I don't know openHAB myself, I can only offer suggestions, so you will need to test and validate yourself.

[MickPo]

Thanks fvanroie. That works a treat. Reconfiguring to reference hasp/+/state/foo and to send commands to hasp/broadcast/Command/meh etc was straightforward. I'm now in the process of creating separate small objects for the individual plate properties.

[smcgann99]

You should be able to have a unique topic for each plate, so you can differentiate between MQTT messages for a specific plate, e.g. idle etc.
But for buttons actions, also listen on hasp/#/state/ so that "any" plate button can trigger your rules.
Similarly if you want to send from openHAB to ALL plates to update, then use the broadcast topic.

[MickPo]

Hi smcgann99,

Thanks for the reply. This looks good and seems like it would require minimal modification of the config that I have running in openHab however it doesn't seem to be possible to use wildcards in the way that you suggest (see above). Maybe there's something that I'm missing in the configuration. Does this work in Home Assistant?

[smcgann99]

I don't use HA I use it with Node Red, but wildcard is a standard thing in MQTT.

[arovak]

If you want to catch state events from all plates you will need to set a channel trigger.
For my rules I use a specific separator to be able to filter on the topic received as well as the value received.

You can set a rule that triggers on this channel.
For example

This is a simple sample rule DSL that is the base for a lot of my rules.
Please note that this uses a JS transformation that you need to add to openHAB.

`
logInfo("openHASP_State_channel.rules", " Channel triggered: {} ", receivedEvent)

var topic = receivedEvent.toString.split("§").get(0)
var payload = receivedEvent.toString.split("§").get(1)
var platevalue = topic.split("/").get(1)
var topicvalue = topic.split("/").get(topic.split("/").size -1)
var jsonkey = transform("JS","my_json_key.js",payload)
var jsonvalue = transform("JSONPATH", "$." + jsonkey, payload).toString.toUpperCase

logInfo("openHASP_State_channel.rules", " Plate: {} Topic: {} [{}] Payload: {}", platevalue, topic, topicvalue , payload)
`
This is the result when you watch the openHAB logs

For the JS transformation, this is a very short and simple javascript.

[MickPo]

Hi Arovak,

That's interesting. As you can see I have the openHASP MQTT thing configured with a channel for every button on each screen etc. Accessing the events via a single channel as you suggest leaves open the possibility of having a much simpler to configure openHASP binding or script library for openHAB.

I see that you have a repo with some openHAB config examples. Building the jsonl config dynamically is interesting. That could work in very nicely with such a binding allowing all of the configuration to happen in one place.

[arovak]

Yes not having to setup a thing for each object on the screen makes that the setup can be much simpler and easier to manage.
You can just build up onto the one channel rule to handle the input from the screen and act upon that.

Per plate I only setup the command things and items and all other interaction is done via rules. Input from plates is handled bu a rule that monitors the channel per plate.
If an action needs to be reflected on multiple screens I just have that rule build a jsonl command and send out the command to 2 screens.
for example this updates the input from my solar panels to 2 screens.

Building the layout on the screen dynamically has it's use cases for sure and also many ways to do in openHAB.
for example, like in the repo you can build the config dynamically from the rule but I also have this working

This rule has the pages.jsonl on the openhab server, reads it and sends it line per line to openHASP
In openHAB and also openHASP you have many options to make it all work together

[MickPo]

Just testing synch/lag with the new configuration. Seems great.

https://youtu.be/YBt3DQPcl4I