Holy Jesus. How come Iâve never seen this before?! @1technophile quick question! Lets entertain the idea of an air conditioner unit that has an ir remote. Do you think I can use this to clone the commands??
Is there any chance that the Switchbot pro meters and especially the co2 meter will be supported in the future? Is there anything I can do to support this like providing logs or something else?
I already implemented and merged this into the development version of tTheengs Decoder 4 days ago, only having data from another user who has the CO2 version though.
If you also have the non-CO2 Meter Pro it would be great if you could supply some raw data samples with Advertisement and advanced data set to true.
If you donât want to wait for the next official release of OpenMQTTgateway with this new decoder included you can install the current development version at
No mesh per se, but you can have as many OpenMQTTGateway around the house as you want, giving them different names, like OMGBedroom, OMG Kitchen etc. and then just use wildcards in your things definitions, e. g.
stateTopic=âhome/+/BTtoMQTT/AABBCCDDEEFFâ
so that they receive the relevant published messages from all gateways.
Alternatively you could also install our site app Theengs Gateway as a central Bluetooth decoder and switch all the OMG gateways to send undecoded messages which the central Theengs Gateway will then automatically pick up and decoder under one single gateway topic.
Either way, are the Govee devices you use with the above implementation already covered by our BLE decoder?
The trouble is that my wife likes to switch off the WiFi during nighttime. I keep the access points running in areas where my main SwitchBot gateway is located. Through the BLE meshing I can still receive measurements from all thermostats in the house. But itâs not absolutely necessary, I installed another access point in the garden this year that stays on at night and should be enough to keep everything running. I think I can just try to switch to OpenMQTTGateway all the way at some point.
Actually I donât have any Govee devices. I have a SwitchBot Meter Plus in every room which is supported already.
Actually I just noticed that from time to time all the item states are set to null instead of actual values. After a couple of minutes everything goes back to normal/actual values.
I added the thermostat with the homeassistant discovery (OH autodiscovery is set to ON).
I hope you havenât told her that Bluetooth is also a 2.45 GHz radio protocol, otherwise the SwitchBot Meters will be off during bedtime as well
Joking aside, depending on where you have Ethernet, you could also install OpenMQTTGateway on a WT32-ETH01.
Donât get me started on OH MQTT discovery I just vented my frustration with it in a little rant in the OH5 thread
Any states being set to null should be addressed there, as it doesnât have anything to do with OpenMQTTGateway and the MQTT messages it publishes.
Youâre best off to keep defining your things manually from my experience.
These messages are actually correctly displayed of broadcasts the devices send out, occasionally without their actual properties, for some manufacturers these are pairing messages to make the devices discoverable to proprietary apps or some sending out multiple protocol messages. This should however not affect the existing values displayed in OH.
The user who helped me imp0lement the initial Meter Pro decoder actually found that if the Meters are connected to the own SwitchBot app such âemptyâ messages are a lot more frequent, while correct value messages were constant once he deleted the Meters from the SwitchBot app. So not sure if oyou also have yours paired with the app or not.
I try not to bother her with these little details of my hobby
I still have some W5500 shields lying around here. Are they supported as well? This might be an option⊠Thank you!
Yeah Iâve got my reasons why I never used it so far⊠I tried a lot of times but it never worked until today. But now I get these null values⊠Well I just setup a new generic mqtt thing again
Yeah I do have mine paired in the app if only for calibration purposes. I never had any problems with the generic things though as the REGEX transform is able to filter out these empty messages. So I guess everything should be fine now with my manual thing definition. If I encounter more issues I will let you know
I honestly donât know if they work connected to an ESP32. best to ask that on the OpenMQTTGateway pro on GitHub,
Another reason Iâm glad I;m stuck with OH2, the MQTT handing there does not make any such funny value resettings when empty messages are being received, and all without any REGEX required ;). Sounds like a new Verschlimmbesserung introduced with OH3 or OH4
In general they do, I have one attached to my enocean gateway. However I only got it working stable with this ethernet library (GitHub - sstaub/Ethernet3: Ethernet library for Arduino and Ethernetshield2 / WIZ550io / WIZ850io / USR-ES1 with Wiznet W5500 chip) not the default ethernet libraries of espressif (or whoever is releasing them). With other libs the esp32 would always hang up after a couple of days, but with this library I have it running for months (years?) without ever having to reboot. Therefore Iâm always a bit sceptical with these pieces of hardware⊠I will ask there when I really want to go down that route, probably I would start with wifi for simplicity first.
Actually it does not do that when youâre using the generic mqtt things, so I guess nothing got worse here from OH2 to OH4. However the json transforms will throw an error when the json element cannot be found. Therefore I added the REGEX transform to get rid of the log spam. The automatically discovered things donât seem to behave that way thoughâŠ
If so set it to false, as this would have only been helpful for investigating a non-CO2 Meter Pro, and should reduce, if not completely stop, any unwanted messages without any real device properties.
I had the same idea when you mentioned this setting yesterday and linked the corresponding channel of the gateway to an item in openHAB (I didnât check in the openMQTT Gateway logs). It was set to OFF so I think this was not the case. Switched it ON and OFF again, so in case was ON it should be OFF now.
Another thing which came into my mind, also while testing HA convention MQTT discovery with 4.3 M4 - what are your settings for "disc" and "ohdisc", visible in the SYStoMQTT settings JSON of your gateway?
Thatâs fine then, as disc is the general HA convention discovery, which switches itself off on the gateway 30 minutes after a start/restart so as not to create discovery messages for any randomly passing by devices,
Behind ohdisc hides
and I frankly donât know if it would still be required in OH 4.3, but best to leave on.
My thinking was that ohdisc might be fall on your gateway, causing your intermittent null values, but obviously it must be something else in the received MQTT value processing.
