I want to send a Zigbee item’s state as a MQTT message whenever it updates.
So far I created a rule that fires whenever my Item’s state updates but it only lets me send a predetermined number. Based on what I found on the forums I need a script for that, but I failed to apply the examples to my scenario.
It will be easiest to help if you show us what you tried and where it went wrong.
I recommend using Blockly if you are not already familiar with programming languages. But to send MQTT in a Blockly Script you’ll need to install a Block Library: MQTT Actions
You can find that in MainUI → Add-on Store → Automation → Block Libraries. Add MQTT from there and you’ll find the MQTT blocks under “Libraries”. It provides a “publish MQTT message” block you can use to publish the state of the Zwave Item.
Note that you only need the MQTT Broker Thing to use this. You don’t need a separate MQTT Generic Thing to publish a message like this using the MQTT action.
If you don’t want to do it that way, link an Item to the “test_sensor3_mqtt_channel” Channel and in your Script, sendCommand to that Item the state of the Zwave Item. You don’t need the Block library for MQTT to do that.
On my system, testing a Blocky rule takes a long time after each change, so I try to avoid using it.
This is what i can’t figure out. If I have a working code example, I can reverse engineer it to my needs, but I couldn’t find any. I do have an item linked to “test_sensor3_mqtt_channel” Channel like you suggested. Can you provide me with a rule based on the data I posted?
Note, it’s probably worth moving to a more powerful machine if your Blockly code is running too slowly on the first run, something like an RPi 4 with 4 GB RAM running 64-bit OS and Java. Otherwise you’ll need to invest in learning a “real” programming language because basic UI rules is not going to be enough, as you can already see. I can’t recommend Rules DSL as it’s basically a dead end.
Note that JS Scripting has the same first run delay as does Blockly. But on 64-bit, that 20-30 second delay becomes 2 seconds or lesson 64-bit.
You cannot avoid script actions and script conditions and be able to do anything meaningful with automation.
Don’t get me wrong, when I first saw Blocky I was thrilled. but that delay is not feasible for someone like me, who needs hundreds trial and errors before getting things right. I thought about switching to 64bit Pi 4, but since the docs recommended 32bit, I stuck to 32bit. I learned C++ on my ESP32 projects, so I’m not afraid of programming languages. Anyway, I inserted your DSL code into rules and I got an error:
[ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'test_sensor3_mqtt' failed: ___ test_sensor3_mqtt_channel.sendCommand(zigbee_temp_3_Temperature.state)
If you are referring to openHABian, the recommendation in the docs are more nuanced now. If you are using Blockly or JS Scripting 64-bit is now recommended.
That’s not a terribly useful error. Double check that the Item names are exactly right. Case matters.
The whole "___ " part of the error is very weird. I’ve never seen that before.
You added the line through the UI form or did you click on the code tab to add the line of code? I’d expect it to look like this:
Scripts are almost never just one line. Maybe that >- only appears if it’s more than one line?
If you are using UI rules, you really shouldn’t be editing the code through the Code tab. Click on the script action and you’ll get a nice code editor to enter your code.
The code tab is mostly helpful for sharing rules on the forum and getting help from the forum and stuff like that but it’s pretty miserable to use to actually enter the code for script actions and conditions.
# There are several ways, choose the one that you like:
test_sensor3_mqtt_channel.command(zigbee_temp_3_Temperature.state)
# The parentheses are optional
test_sensor3_mqtt_channel.command zigbee_temp_3_Temperature.state
# The "shovel" operator is a syntactic sugar for command
test_sensor3_mqtt_channel << zigbee_temp_3_Temperature.state
This is assuming that the item names above are correct.
I don’t see the aforementioned “>-” in the code blocks I provided, so I don’t understand what you mean.
Anyway, I recreated all the things and items, then I created a new rule using code editor instead of code tab, as you instructed. All the names are correct, but the ___ error keeps coming up. I finally got it working by switching from DSL to JS. Out of curiosity I tried to figure out why the DSL rule throws that ___ error, but after many tries I gave up since my problem is solved. Thank you very much for your help.
Side question: how can I remove UoM from that MQTT message?
Instead of
just let me add one more subjective comment (yes, I do this a lot): With a Pi4 (or higher) I would highly recommend to switch to 64bit and enjoy the boost of speed and fun while implementing home automation features. There’s almost nothing you cannot do with blockly.
I have no reason to doubt you, but imagine you’re a new user, it’s your first attempt at OpenHab. You don’t know which version to download, so you go to Installation Overview | openHAB and you read this
yes, your right, this scares new users off. There had been long discussions about this issue and the statement now is already much weaker. The big disadvantage of 32 bit occurred after the introduction of the new java version.
My personal opinion is that a clear recommendation for 64 bit together with Pi4 or higher would be appropriate now. Rule development with Blockly or JavaScript is awful with the 15sec delay after every change. With 64bit you have a delay of 1-2sec before the first run so that’s completely fine.
But it’s not a big deal to start fresh and import your old config.
I think that section of the docs were missed when the recommendation was updated. Even in openHABian, the biggest booster for 32-bit, has changed the recomendation in the openHABian docs:
64 bit?
RPi 3 and newer have a 64 bit processor. There’s openHABian images available in both, 32 and 64 bit. Choose yours based on your hardware and primary use case. Please be aware that you cannot change once you decided in favor of either 32 or 64 bit. Should you need to revoke your choice, export/backup your config and install a fresh system, then import your config there.
Use the 64 bit image versions but please be aware that 64 bit always has one major drawback: increased memory usage. That is not a good idea on heavily memory constrained platforms like Raspberries. If you want to go with 64 bit, ensure your RPi has a mimimum of 2 GB, 4 will put you on the safe side. You can use the 32 bit version for older or non official addons that will not work on 64 bit yet. Note there’s a known issue on 32 bit, JS rules are reported to be annoyingly slow on first startup and in some Blockly use cases.
On x86 hardware, it’s all 64 bit but that in turn once more increases memory usage. A NUC to run on should have no less than 8 GB.
It’s also worth mentioning that no one really knows what bindings are being referred to with the “some add-ons use libraries…” and that warning is likely no longer true. But we don’t know what bindings it was referring to in the first place and no one has volunteered to check all 350+ bindings to verify it’s no longer the case so the warning remains.
Maybe we could ask 64 bit users to report which bindings they’re successfully using and compile a list?
Also, many users (like myself) may consider moving to 64 bit so a suggested procedure could be published, instead of folks just finding it buried in a discussion thread about some unrelated issue?
Anyone who is willing to take that on is welcome to. Those sorts of polls have had only limited success in the past.
I do know that there is a sizable portion of OH users who are running on 64-bit so if there were an add-on that is even moderately popular would have already had people complaining that it doesn’t work on 64-bit.
The procedure is outlined in the openHABian docks right at the top. It could be added to the main installation docs too, but frankly I’m not certain the discussion even belongs there but instead should be in the Linux installation. Users running Windows and Mac don’t really have much of a choice when it comes to OS.
But the procedure is:
take a backup
reinstall the OS
restore the backup
Exactly how to do 1 and 2 is going to depend on how you’ve installed and configured your system. openHABian and Linux installs have openhab-cli backup and openhab-cli restore.