Its just receivedCommand. https://docs.openhab.org/configuration/rules-dsl.html#implicit-variables
To expand on that, the receivedCommand ābelongsā to the rule that you refer to it within (which could be triggered by one of several Items or Groups). Thatās part of what makes it useful, it isnāt associated with any particular Item.
Do you have access to the code of your 433MHz to MQTT gateway
I suggest that you change the payload to a json format eg:
155521: 15 says first sensorboard, voltage with 5521mV
110459: 11 says first sensorboard, humidity with 45.9%
130618: 13 says first sensorboard, temperature with 21,8 Degree
{ sensor:15, value:5521 }
{ sensor:11, value:45.9 }
{ sensor:13, value:21.8 }
and so on
Then you can subscribe to the topic and do a JSONPATH transform on the inbount mqtt subscription for each item. No rulesā¦
Ok so I just hab a look at the openMQTTGateway wiki and some user reviews in other forums. I knew I saw that before and I couldnāt remember why I didnāt choose that solution.
You could have chosen a better solution. RFLink works very well and publishes information with sensor name and values. I process it though node-red and into OH via MQTT. openMQTT doesnāt review very well with usersā¦
If you want to stick with your receiver the I recommend the following solution: Node-Red!
Get a node subscribing to you 433 gateway
Process the info in a function node and publish out on MQTT to different items on OH
For example the payload 155521 could get transformed by node-red into:
topic: Sensor/Voltage payload:5521
You just need your OH item to subscribe to Sensor/Voltage and off you goā¦
If you need help with node-red, I am available
No rules in OH. Async processing in node-red. Automatic updating of value in OH.
1 Like
@vzorglub Thank you for your feedback.
So i looked into RFLink and no, i will not buy another microcontroller just to get serial input which then has to be transfered by my esp8266.
The Node Red approach looks promising, but then then i said to myself:
Why not use the advantage of open source sw?
So what i did was take the OpenMQTTGateway and added a simple function in the RFSend Path.
Also added defines for my sensors like minimum value, maxvalue, and sensorinformation and mqtt topic to
transfer the data to.
My new function first checks if the recieved RF Value is one of my sensor values, if so
the value is transformed in one easy line and then send with the corresponding mqtt topic.
If the recieved value was not from one of my sensorboards then the default is the old handling of the message in OpenMQTTGateway style.
As i enabled OTA Updates for my gateway it is a simple compile and push (okay with pw for a little bit of security).
So i got rid of the neccessarity of using the rules, cause even with the great help of rikosak the outcome was that the problem itself is the shortcoming of OpenMQTTGateway in combination with the rule trigger problem.
The recieve command made it a little bit better, but only if i use one or two of my 8 sensor boards. With 8 sensorboards the usage of the rules is complicated, slow and errorprone.
I have to admit that i tried to āhealā the problem at the end of the data chain and not really touched the real issue.
So i say thank you to all the people who helped me in my search for enlightment:
@rikosak, @rossko57, @Josar, @Kevin and last but not least @vzorglub
In the long run i will try to adapt the RFLink to my NodeMcu with sending MQTT Data directly or at least Json conform data, because i like the approach of understand a lot more proctols than only RCSwitch. But this will be a side project. But if i get it working, i will post it here in this forum.
For future reference i will post later my code changes to the OpenMQTTGateway.
So here are the changes:
Inside of ZFGatewayRF.ino
boolean RFtoMQTT(){
.. original code here till
if (!isAduplicate(MQTTvalue) && MQTTvalue!=0) {// conditions to avoid duplications of RF -->MQTT
// after the above if i added the following:
if (DecideMQTTTopic(MQTTvalue)) return true; // Check for known MQTT Sensor Topic, if not known, do the standard
.. old code of the function
}
//And my new function looks like this, given here example for one sensor!
boolean DecideMQTTTopic(unsigned long MQTTvalue_raw) {
boolean result = false;
String value = "";
if((start_sensor1_voltage < MQTTvalue_raw) and (MQTTvalue_raw < end_sensor1_voltage)) {
// Voltage First Sensor found
value = String(MQTTvalue_raw - start_sensor1_voltage);
result = client.publish(topic_Sensor1_volt,(char *)value.c_str());
return result;
}
if((start_sensor1_temp < MQTTvalue_raw) and (MQTTvalue_raw < end_sensor1_temp)) {
// Temperature First Sensor found
float calc_temp = (MQTTvalue_raw - start_sensor1_temp-sensor1_temp_offset)/10;
value = String(calc_temp); // 130400 is equal 0.0 degree, and 130000 is equal -40.0 degree
result = client.publish(topic_Sensor1_temp,(char *)value.c_str());
return result;
}
if((start_sensor1_hum < MQTTvalue_raw) and (MQTTvalue_raw < end_sensor1_hum)) {
// Humidity First Sensor found
float calc_temp = (MQTTvalue_raw - start_sensor1_hum) / 10;
value = String(calc_temp);
result = client.publish(topic_Sensor1_hum,(char *)value.c_str());
return result;
}
}
//Also inside the config_RF.h i added the following, again example for one sensorboard
/*-------------------MQTT Topics and mapping to RF Sensor ----------------------*/
#define start_sensor1_voltage 150000
#define end_sensor1_voltage 159999
#define topic_Sensor1_volt "sensor/bath/voltage"
#define start_sensor1_temp 130000
#define end_sensor1_temp 139999
#define sensor1_temp_offset 400
#define topic_Sensor1_temp "sensor/bath/dht/temperature"
#define start_sensor1_hum 110000
#define end_sensor1_hum 119999
#define topic_Sensor1_hum "sensor/bath/dht/humidity"
So, for me the adaption was rather easy and through the OTA Update also doable for adding later more sensors.
Just a sidenote: with now 8 sensorboards running i have not a single missed sensorvalue through to fast sending 
After some time the curiosity of NodeRed came up again and i tried the āconversionā via NodeRed and
i have to say: It was even easier. So if someone had no coding background then the NodeRed way will
be much easier for them.
So a Thumbs Up @vzorglub, great advice!