Maybe somebody can help me with these issues.
In my Home automation environment I only use MQTT bindings
My MQTT client are publishing several types of variable (Boolean, Integer, Float and String).
e.g (temperature):
mosquitto_sub -h HaBroker2.local -u MQTT -P MQTT -t Home/SF/nb/254/2/040
26.60
Some of them are published periodically, other are only on request.
For all types of variable the request is obtained by subscribing a READ topic
e.g
mosquitto_pub -h HaBroker2.local -u MQTT -P MQTT -t Home/SF/sb/254/2/040 -m READ
My OH2 (2.5) configured according to the MQTT status and command and is working however I have some issues:
First issue:
While staring OPENHAB most of the variables are with an undefined or NULL state
So before starting to configure some items I need to get the current value of it, so the need to scan these variables periodically, or at least at the start of OH.
Question: Is it possible to start a script via the rules each time OH is started?
Second issue:
To ensure the current state of my MQTT variables, it would be good to poll theses ones regularly.
This can be done from a bash or python script
Question: Should I run this script from OH rules or from the crontab?
Third issue:
Rather than polling the variables at regular interval it would be better to enforce a polling each time I access one WEB page where these variable are displayed.
Question: Is it possible to define OH rules associated to a specific page?
Last issue:
Most of the items are defined as Setpoint / number, so if I use the item names as defined in OH I can’t send a command with the “READ” parameter because only numbers are allowed.
Question: Any idea to bypass this constraint?
Why?
This is not what the mqtt protocol was designed for and this is why you are having problems
Issues one, two, and three
Make All your devices to report periodically and on change. Get rid of this on request polling and use RestoreOnStartup with persistence
Last issue, use another item
That doesn’t help much with mqtt.
The binding will set the items to UNDEF as it should and the devices should provide a periodic update or mqtt retain topics will update the items.
This is how mqtt is meant to be used
First issue: this is what retained messages are for. If the message published represents a state and it doesn’t expire quickly (e.g a temp reading that great published every two minutes) it should be published with retained set. This will cause the MQTT broker to save the message and when a client subscribes to that topic the broker immediately published the value.
But yes, there is a System started rule trigger that runs when oh starts or reloads a .rules file.
Second issue really makes absolutely no sense in an MQTT context. If you’re devices have something to publish they just publish it. If it’s a state, they use retained. If it’s ephemeral, the client should remain NULL until what every it to happens again. There should be no polling in an MQTT system. One if the driving tenants of MQTT is “thou shalt not impose on the subscribers.” Subscribers should be able to subscribe to the topic and get what they need whenever. They need not be subscribers when the message is actually published.
Third, no, there is no way to fire a rule when a page is accessed. But the only reason you need to do this in the first place is you have a broken mqtt architecture. You should never be forced to poll in an MQTT context.
If it’s a fixed pattern, you can apply formatting to the outgoing messages similarly to how you format labels on the Sitemap. If you need more, all of the transformations are available to you.
Not any more. As of 2.5M5 it will not override restireOnStartup and leave the items NULL if they are subscribed to topics without retained messages.
No nothing imposes an MQTT client to send (pubish) periodically data
Persistence will not help because it will reflects old values that are probably outdated
You ask me to modify a working model to fit to the constraint of OH, while OH should be flexible enough to fit any kind of configuration
Thanks, override restireOnStartup explains why after updating to OH2.5 most of my rules are loggin errors at start-up, because some variables are not initialized yet. @rlkoshak
OK thanks for your comments, to keep it simple I will implement my script in the crontab that will refresh MQTT variables.
NB: I think that the capability to activate rules according to the displayed page should be an improvement (many display devices are allowing that).
Robert
Please don’t change the topic by explaining me how to work with MQTT …
Yes: second issue makes sense, because I am not talking about dynamic variables but well configuration parameters such as thresholds or configuration options that are set once.
So I expect OH to show me the current parameter value before I can change it, the reason I need to query them before change, currently regular polling is the only way.
I am working in a multiple MQTT broker environment so persistence is not the solution, because it might be possible that the parameter was changed by another broker than the one running OH.
Now a possible solution is to add to the site map a button to request/update the value, unfortunately the query is a string (READ) and the answer is number so I can not use the same item, because this kind of combination is not possible with OH (which is by the way OK for me) .
Alternatively I can, for each parameter create a text item for query , but this is very cumbersome to use.
Robert
Perhaps you can expand on “page” - page of what? Is this one of the standard OH UIs, or is it something else under your control? Or you can be flexible?
I have to say your whole approach seems wrong - you’re trying to invent a workaround for remote services failing to advise you when something changes. The general philosophy of MQTT is that services should publish their “interesting things” unprompted; trying to force it into a polling model is a poor fit. Should you be looking at the other end?
Again, understand me good, I don’t want to poll MQTT clients, I just want to change operational parameters using the same MQTT protocol. Now the reason of the poll is to inquire about the state these configuration parameters. I don’t want my MQTT devices to send periodically hundreds of configuration parameters just to be sure that OH is updated.
Of course not. This is why the usual approach is to send changes. openHAB and/or the broker(s) are perfectly capable of remembering the most recent value.
Simplicity, simplicity, simplicity! Don’t add too many “bells and whistles” but provide a solid building block which can easily be integrated into other solutions. Be simple to implement.
Publish/subscribe messaging. Useful for most sensor applications, and enables devices to come online and publish “stuff” that hasn’t been previously known about or predefined.
Zero administration (or as close as possible). Behave sensibly in response to unexpected actions and enable applications to “just work” e.g. dynamically create topics when needed.
Minimise the on-the-wire footprint. Add an absolute minimum of data overhead to any message. Be lightweight and bandwidth efficient.
Expect and cater for frequent network disruption (for low bandwidth, high latency, unreliable, high cost-to-run networks)… → Last Will and Testament
Continuous session awareness → Last Will and Testament
Expect that client applications may have very limited processing resources available.
Provide traditional messaging qualities of service where the environment allows. Provide “quality of service”
Data agnostic. Don’t mandate content formats, remain flexible.
Your polling approach with stuff appended to the message violates at least 2 (polling is not publish/subscribe) and 4 (you have to add READ to some messages) and one could argue 7 (subscribing to a topic and reacting to it requires more resources than just having the client publish when necessary.
The whole reason retained was created is because the publisher is in the best position to know when it’s appropriate to publish. But the publisher cannot and should not have to know whether the subscribers are online when it does publish. So the message is retained and when the subscribers do connect, they will get the message.
Nothing imposes on me to shovel the snow on my walk with the handle of my snow shovel, but it’s so much more effective and easier if I use the shovel as it was designed to be used.
The problem is that is only needed in a polling architecture and computer scientists, programmers and other experts in these fields will go to great lengths to avoid a polling architecture. It’s more complicated, less responsive, and has a much much larger networking and CPU requirements. In short, it’s harder to create and consumes more resources for a less responsive system. When given a choice between polling any anything else, anything else will win.
Except using MQTT properly is the solution to your problem. Anything else is a bandaid at best.
No it’s not. Publish the message as a retained message and that message will remain there forever. Every time OH connects it will receive that message immediately. No need to poll and OH will show you the current parameter every time.
I can definitely see some cases where one would want to run multiple brokers, but typically one then bridges the brokers. The fact that you are running multiple brokers should be transparent to the clients. Publish the retained message to one of the brokers and that retained message will be available on all the bridged brokers.
Yes this is possible. I explained how above using the outgoing message formatting or a transformation.
Then publish them with retained set. Then you don’t need to poll them.
I am not violating rule 2, polling is just publishing a READ to a device for a specific variable
I am compliant with rule 3. Device configuration parameters are predefined like a Target temperature of a thermostat which is store in EEPROM
rule 4. Bandwidth usage is minimized by the size of the message and the encoding type, and I don’t want to poll, the only the reason is to inquire about a specific value and I can’t rely on persistence, typically if I want to change the target temperature of the thermostat, that can also be changed manually.
It would not be necessary for me to regularly poll if there was a way to refresh some variables while accessing OH relevant page.
rule 5. MQTT uses datagrams that may be lost, one of the reason to use the READ message to ascertain values if necessary but in particular to modify predefined parameters .
Adding transformation will add an unnecessary level of complexity while using a simple script will solve my problem
If loss of a message is a concern, you use QOS 1 (deliver the message at least once) or QOS 2 (deliver the message exactly once). There is no chance of a loss because the broker doesn’t consider it delivered until it receives and acknowledgement from the subscriber.
Putting “READ” in the Outgoing Value Format is more complex than writing a script?
In my opinion, writing a script adds way more unnecessary complexity than that.
Look, I don’t give a fig what you actually do in your system. You are gonna do you. But I do care about all those poor people who come along and read threads like these and think this is a good way to build a system using MQTT. It’s not. You are completely ignoring features built into MQTT and the MQTT binding that can solve all your problems and make your life so much easier, and insisting your approach is just as good.
Want to make sure that all your openHAB Items always have the most recent message? Publish those message to the MQTT topics using the retained flag and use at least QOS 1. That’s it. Add two little flags to what ever publishes the message in the first place and OH will always show the most recent message published. No need for persistence. No problem with stale messages or old data. No need to poll.
When things change on the device, it publishes the message retained and if OH happened to be offline when the message was published it doesn’t matter because it will get the message when it connects and the Item will be initialized to the correct and most recent value.
