Hello,
Could you post your user_config without your passwords?
Sure, will post them as soon as I’m home.
/*-------------------VERSION----------------------*/
#define OMG_VERSION "0.6.2"
/*-------------DEFINE YOUR NETWORK PARAMETERS BELOW----------------*/
//MQTT Parameters definition
//#define mqtt_server_name "www.mqtt_broker.com" // instead of defining the server by its IP you can define it by its name, uncomment this line and set the correct MQTT server host name
#define mqtt_server "x.x.x.x"
#define mqtt_user "xxx" // not compulsory only if your broker needs authentication
#define mqtt_password "xxx" // not compulsory only if your broker needs authentication
#define mqtt_port 1883
#define Gateway_Name "OpenMQTTGateway"
#define version_Topic "home/" Gateway_Name "/version"
#define will_Topic "home/" Gateway_Name "/LWT"
#define will_QoS 0
#define will_Retain true
#define will_Message "Offline"
#define Gateway_AnnouncementMsg "Online"
//#define MDNS_SD //comment if you don't want to use mdns for discovering automatically your ip server, please note that MDNS with ESP32 can cause the BLE to not work
/*-------------DEFINE YOUR NETWORK PARAMETERS BELOW----------------*/
// Update these with values suitable for your network.
#if defined(ESP8266) || defined(ESP32) // for nodemcu, weemos and esp8266
#define wifi_ssid "ssid"
#define wifi_password "pwd"
#else // for arduino + W5100
const byte mac[] = { 0xDE, 0xED, 0xBA, 0xFE, 0x54, 0x95 }; //W5100 ethernet shield mac adress
#endif
const byte ip[] = { x, x, x, x }; //ip adress
// Advanced network config (optional) if you want to use these parameters uncomment line 158, 172 and comment line 171 of OpenMQTTGateway.ino
const byte gateway[] = { x, x, x, 1 }; //ip adress
const byte Dns[] = { x, x, x, 1 }; //ip adress
const byte subnet[] = { 255, 255, 255, 0 }; //ip adress
/*-------------DEFINE YOUR OTA PARAMETERS BELOW----------------*/
#define ota_hostname Gateway_Name
#define ota_password "xxx"
#define ota_port 8266
/*-------------DEFINE PINs FOR STATUS LEDs----------------*/
#define led_receive 40
#define led_send 42
#define led_error 44
// VCC ------------D|-----------/\/\/\/\ ----------------- Arduino PIN
// LED Resistor 270-510R
/*-------------DEFINE THE MODULES YOU WANT BELOW----------------*/
//Addons and module management, comment the Z line and the config file if you don't use
#ifdef ESP8266 // for nodemcu, weemos and esp8266
#define ZgatewayRF
#include "config_RF.h"
//#define ZgatewayRF2
//#define ZgatewaySRFB
//#include "config_SRFB.h"
//#define ZgatewayIR
//#include "config_IR.h"
//#define ZgatewayBT
//#include "config_BT.h"
//#define ZsensorINA226
//#include "config_INA226.h"
//#define ZsensorHCSR501
//#include "config_HCSR501.h"
//#define ZsensorADC
//#include "config_ADC.h"
//#define ZsensorBH1750
//#include "config_BH1750.h"
//#define ZsensorTSL2561
//#include "config_TSL2561.h"
//#define ZsensorBME280
//#include "config_BME280.h"
//#define ZsensorDHT // If you uncomment this you can't use I2C due to the fact that I2C use also D1
//#include "config_DHT.h"
//#define ZgatewayRFM69 // If you uncomment this you can't use RF and BT due to the fact that RF use also D8 and BT use also D6/D7
//#include "config_RFM69.h"
#elif ESP32
#define ZgatewayRF
#include "config_RF.h"
//#define ZgatewayRF2
//#define ZgatewayIR
//#include "config_IR.h"
//#define ZgatewayBT
//#include "config_BT.h"
//#define ZsensorINA226
//#include "config_INA226.h"
//#define ZsensorHCSR501
//#include "config_HCSR501.h"
//#define ZsensorADC
//#include "config_ADC.h"
//#define ZsensorBH1750
//#include "config_BH1750.h"
//#define ZsensorBME280
//#include "config_BME280.h"
//#define ZsensorDHT // If you uncomment this you can't use I2C due to the fact that I2C use also D1
//#include "config_DHT.h"
//#define ZgatewayRFM69 // If you uncomment this you can't use RF and BT due to the fact that RF use also D8 and BT use also D6/D7
//#include "config_RFM69.h"
#else // for arduino + W5100
#define ZgatewayRF
#include "config_RF.h"
//#define ZgatewayRF2 // too big for UNO
//#define ZgatewayRFM69 not tested
//#include "config_RFM69.h"
//#define ZgatewayIR
//#include "config_IR.h"
//#define ZgatewayBT
//#include "config_BT.h"
//#define ZsensorINA226
//#include "config_INA226.h"
//#define ZsensorDHT
//#include "config_DHT.h"
//#define ZsensorBH1750
//#include "config_BH1750.h"
//#define ZsensorTSL2561
//#include "config_TSL2561.h"
//#define ZsensorBME280
//#include "config_BME280.h"
//#define ZsensorHCSR501
//#include "config_HCSR501.h"
//#define ZsensorADC
//#include "config_ADC.h"
//#define ZgatewayRFM69 not tested
//#include "config_RFM69.h"
//#define ZsensorINA226
//#include "config_INA226.h"
#endif
/*----------------------------OTHER PARAMETERS-----------------------------*/
/*-------------------CHANGING THEM IS NOT COMPULSORY-----------------------*/
/*----------------------------USER PARAMETERS-----------------------------*/
#ifdef ZgatewaySRFB
#define SERIAL_BAUD 19200
#else
#define SERIAL_BAUD 115200
#endif
/*--------------MQTT general topics-----------------*/
// global MQTT subject listened by the gateway to execute commands (send RF, IR or others)
#define subjectMQTTtoX "home/commands/#"
#define subjectMultiGTWKey "toMQTT"
//variables to avoid duplicates
#define time_avoid_duplicate 3000 // if you want to avoid duplicate mqtt message received set this to > 0, the value is the time in milliseconds during which we don't publish duplicates
/*-------------------ACTIVATE TRACES----------------------*/
#define TRACE 1 // 0= trace off 1 = trace on
magically a recomplie solved it. I don’t how, but at least the voltage from your example code for the outside sensor works. The rest is of the two values got not even stored, but i look for my self first and ask later 
Edit:
Putting ~5V to the reciever eliminated the message recieve problems.
I use a Node V3 which does not put 5V to VIN. So i have to do something to get this working, but your sw works fine.
Strange that the normal send and recieve examples from rcswitch worked with 3.3V.
1 Like
Here is a new device compatible with OMG on ESP32 and other boards + HM10
Hi,
i have a little question regarding the mapping of the MQTT Events to Openhab Items.
As you suggested on your linked blog, you used a mapping list for each value.
In my opinion a approach that leads to a lot of warnings in the events.log of openhab.
I have to sensors(humidity, temperature and voltage) using both openmqttgateway.
This leads for each of these six items to 5 warnings as the mapping could not be found.
Looks like this:
Could not transform '130632' with the file 'Mapping_Sensor1_Voltage.map' : Target value not found in map for '130632'
Do you have any other idea what can be done to reduce these number of warnings.
Maybe a approach in the rules section could help?
My idea would be something as follow:
define a dummy item in the items list which gets all mqtt updates.
Then define a rule like this:
rule "MQTT_Transform"
when
Item MQTT_Trigger_Dummy changed
then
if (MQTT_Trigger_Dummy < 999999) { // Value is not error
if ((MQTT_Trigger_Dummy >= 110000) and (MQTT_Trigger_Dummy <= 119999)) {
// a humidity value from sensor 1 identified
FF_Bath_Humidity.postUpdate((MQTT_Trigger_Dummy - 110000)/10)
} else if ((MQTT_Trigger_Dummy >= 130000) and (MQTT_Trigger_Dummy <= 139999)) {
// a temperature value from sensor 1 identified
FF_Bath_Temperature_dht.postUpdate((MQTT_Trigger_Dummy - 13400)/10)
} else if ((MQTT_Trigger_Dummy >= 150000) and (MQTT_Trigger_Dummy <= 159999)) {
// a voltage value from sensor 1 identified
FF_Bath_Voltage.postUpdate((MQTT_Trigger_Dummy - 150000))
}
}
end
Please be aware that this is not yet tested. But a aproach like this also be a idea.
Or what do you think?
Hello,
Yes i’m also getting these warnings, for my curiosity which kind of temperature/humidity sensor do you use?
Your rule seems a good idea I’m interested on your feeback from tests
Hi,
so to first satisfy your curiosity i use the dht22, but with two ATMega328P.
So now the good part:
I got it working without any warnings.
A few words first: i changed your the temperature default value to 130400, as the DHT22 could measure from -40.0 Degree up to +80.0 Degree. So with subtracting -400 (for -40.0) we still got 130000 as a transferable value and not a 129600.
The bad part:
It is a ugly piece of code!
//First you need this as the message can come in very quickly and you don't want your rule execution broken
import java.util.concurrent.locks.ReentrantLock
// Then this:
var Number mqtt_calc_dummy // will be later used for calculation the real value, bad workaround
val ReentrantLock lock = new ReentrantLock() // for locking and unlocking rule execution
// now to the ugly rule part:
rule "MQTT_Transform"
when
Item MQTT_Trigger_Dummy changed
then
if(!lock.isLocked){
lock.lock()
try {
if (MQTT_Trigger_Dummy.state < 999999) { // Value is not error
if ((MQTT_Trigger_Dummy.state >= 110000) && (MQTT_Trigger_Dummy.state <= 119999)) {
// a humidity value from sensor 1 identified
mqtt_calc_dummy = MQTT_Trigger_Dummy.state
mqtt_calc_dummy = mqtt_calc_dummy - 110000
mqtt_calc_dummy = mqtt_calc_dummy / 10
// having the calculation in one line magical doesn't work
if (mqtt_calc_dummy >= 0) { // if value < 0 something fishy
FF_Bath_Humidity.postUpdate(mqtt_calc_dummy)
}
lock.unlock();
return;
}
if ((MQTT_Trigger_Dummy.state >= 130000) && (MQTT_Trigger_Dummy.state <= 139999)) {
// a temperature value from sensor 1 identified
mqtt_calc_dummy = MQTT_Trigger_Dummy.state
mqtt_calc_dummy = mqtt_calc_dummy - 130400
mqtt_calc_dummy = mqtt_calc_dummy /10
if (mqtt_calc_dummy > -40.0) { // if value < -40.0 then something fishy
FF_Bath_Temperature_dht.postUpdate(mqtt_calc_dummy)
}
lock.unlock();
return;
}
if ((MQTT_Trigger_Dummy.state >= 150000) && (MQTT_Trigger_Dummy.state <= 159999)) {
// a voltage value from sensor 1 identified
// mqtt_calc_dummy = ((MQTT_Trigger_Dummy.state - 150000)) // one line doesn't work
mqtt_calc_dummy = MQTT_Trigger_Dummy.state
mqtt_calc_dummy = mqtt_calc_dummy - 150000
if (mqtt_calc_dummy > 0) { // if value < 0 then something fishy
FF_Bath_Voltage.postUpdate(mqtt_calc_dummy)
}
lock.unlock();
return;
}
} else {
logInfo("Sensor", "Sensor send error code " + MQTT_Trigger_Dummy.state)
lock.unlock();
return;
}
} finally {
lock.unlock()
}
}
end
And the item looks like this:
Number MQTT_Trigger_Dummy "[%.1f]" {mqtt="<[openhabian:home/433toMQTT:state:default]", expire="10m, 999999"}
This sets the one and only item to work with the rule above.
1 Like
For the next evolutions of OpenMQTTGateway I would like to have your advices, here is a poll that will take 30 seconds to fill and that will give us usefull insights:
You can now exchange and share about OpenMQTTGateway on a dedicated forum:
1 Like
V0.9 is out!
This big release add some exciting features to the OMG current functionnalities, in particular the add of the pilight library thanks to the work of @steadramon & @puuu. By adding this library we clearly extend the number of RF protocols covered by OMG, for example we can now support some 433mhz temperature sensor like this one.
V0.9 includes also a new json API to enable to pass the advanced parameters directly into the payload.
Finaly with the help of @animavitis we implemented auto discovery for HASS that should work with the new Openhab 2.4 MQTT binding.
Enhancements:
- Enable wifiManager.setConfigPortalTimeout(xxxx) to avoid OMG issues after a MQTT server restart
- MQTT Discovery
- Json implementation
- Add Home Assistant MQTT room presence support
- multi gpio input module
- Code size reduction to have enable Arduino UNO with one gateway at a time
- ESPilight integration
- Add received value into the subject
Wiki/comments:
- Doc update with the new json API, you can find the previous documentation here
- Add of Pilight user guide
Bug fixes:
Others:
Thanks to all the contributors and among others:
@animavitis
@steadramon
@StryKaizer
@johnou
@alibahba
@McGr3g0r
@belidzs
And all who submitted good issues, feedback and wiki improvements.
Regarding the OpenHAB manual integration with Json I would need the help of the OpenHAB community to update the different examples we have in stock
1 Like
Is this still an issue or has it been solved?
It is still an open point.
There is another MQTT ESP8266 based RF gateway that does not have the issue of RF vs RF2… your project seems way cooler, but this limitation is the biggest hesitation I have.
When I have time I might try to contribute, but doubt I can in the near future.
In any case, I have a few ESP32s available, I will try your opengateway again on one of them.
This is the fact that you cannot receive at the same time with RF and RF2 that is a pain for you?
Correct. I remember that some devices I had only worked on RF2, and others only on RF.
I wanted a solution that can make me completely eliminate my nanoCUL.
Hi, don’t know if I stumble correctly but was looking for integrate this kind of item in OH and discovered about OMG
Motion Sensor Sistema NEO CoolCam NAS-PD01W intelligente WiFi PIR
Is it the right way? Or does this object protocol is not suitable?
HI,
Yes the protocol used by this object is not suitable.
You can find compatible devices in the list below:
For info OMG can be used on Sonoff RF Bridge with pilight, extending consequently the list of compatible protocols, here is how :
Hello!
First of all - grat job!
Now I’ve got working nodemcu +RF and using nodemcuv2-rf-firmware.bin
I would like to use one nodemcu for a RF+RF2+IR+DHT22 gateway (later I add BT but not now).
When I flash it with nodemcuv2-all-firmware.bin it isn’t connect to mqtt broker 
Which BIN file should I use?
1 Like