[Solved] Sending Item's state via MQTT

Setup, Configuration and Use Beginners
1

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.

Item’s state (temperature) that i want to send:

UID: zigbee:device:zigbee_gate:a4c138cda009b29c
label: zigbee_temp_3
thingTypeUID: zigbee:device
configuration:
  zigbee_macaddress: A4C138CDA009B29C
bridgeUID: zigbee:coordinator_ember:zigbee_gate
channels:
  - id: A4C138CDA009B29C_1_temperature
    channelTypeUID: zigbee:measurement_temperature
    label: Temperature
    description: null
    configuration:
      zigbee_reporting_polling: 7200

MQTT Generic thing that I’m using:

UID: mqtt:topic:mqtt_broker_openhab:test_sensor3_mqttthing
label: Test Sensor 3 MQTT Thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mqtt_broker_openhab
channels:
  - id: test_sensor3_mqtt_channel
    channelTypeUID: mqtt:number
    label: Test Sensor 3 MQTT Channel
    description: ""
    configuration:
      commandTopic: test_sensor3

Rule:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: zigbee_temp_3_Temperature
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: 123
      itemName: Test_Sensor_3_MQTT_Thing_Test_Sensor_3_MQTT_Channel
    type: core.ItemCommandAction

openHAB 4.1.2 running on Pi

Edit:
Adding the final solution below for future readers:

  1. Create a new rule with “an item state is updated” condition in “When”.
  2. In “Then” choose “execute an inline script” and choose “ECMAScript”
  3. Type the code using “Edit script” instead of the “Code” tab
  4. The script is just a single line (change both “youritemname” to your item names:
items.youritemname.sendCommand(items.youritemname.state)
2

Correct, you need a script.

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.

3

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?

4

Well, since you don’t want to use Blockly:

Rules DSL: test_sensor3_mqtt_channel.sendCommand(zigbee_temp_3_Temperature.state)

JS Scripting: items.test_sensor3_mqtt_channel.sendCommand(items.zigbee_temp_3_Temperature.state)

jRuby: test_sensor3_mqtt_channel command zigbee_temp_3_Temperature.state

And just for completeness

Blockly:

image
image1096×116 12.9 KB

Of course replace the “MyItem” with your Items.

All of the above have extensive reference documents:

And there are generic documentation on how rules work in general:

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.

5

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)

Here’s the full rule code

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: zigbee_temp_3_Temperature
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: test_sensor3_mqtt_channel.sendCommand(zigbee_temp_3_Temperature.state)
    type: script.ScriptAction
6

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:

script: >-
  test_sensor3_mqtt_channel.sendCommand(zigbee_temp_3_Temperature.state)

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.

image
image1538×366 21.3 KB

image
image2712×874 321 KB

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.

7

It should be:

# 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.

8

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

22.78 °C

I want to send just

22.78

.

9

Exactly, that’s my point. That should be there. It’s in all my rules.

Make the Item linked to the MQTT channel be just a Number, not a Number:Temperature would be simplest.

Since you are using JS, use items.nameofitem.numericState instead of .state.

10

Again, Thank you very much!

11

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.

12

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

image
image995×153 11.4 KB

Would you go for 32bit or 64bit?

13

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.

14

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.

64-bit?

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.

15

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?

16

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:

  1. take a backup
  2. reinstall the OS
  3. 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.