Also, there are some issues with the protocol being recognized as either Tunex or Xiron. Only the Tunex ID gets updated regularly.
well, it’s ok if it oscillates between 2 IDs, but I saw more…:\
regarding the bug, in my case it happens with RFLink AND OMG… maybe they both use some common code like rcswitch or something? as I have receivers relatively close to se sensors and still, that happens so I don’t think it’s a poor reception… but I might be wrong
Yes, I’ve seen that too (in addition to Tunex and Xiron there are some other entities that appear). It seems that manufacturers are using a lot of low quality parts and that causes interference. This is my setup for rflink (I’m ignoring all the entities below so that only tunex remains):
rflink:
port: /dev/ttyUSB0
wait_for_ack: false
reconnect_interval: 600
ignore_devices:
- auriol*
- bl*
- fine*
- renkforcee*
- alecto*
- digitech*
- xiron*
1 Like
I haven’t spent a lot of time investigating, need to have closer look if mine oscillate within one name or they change names as well. It’s not that easy, is it?
The most difficult part is understanding the binary language of moisture vaporators 
I had to turn on debugging for rflink as it is usually off (keeping it on all time will flood the HA log) and let it settle for about a half of hour; in the beginning there are multiple IDs reported for the same device however, after some time, a pattern should be obvious for the ID that is consistently updated.
Then replaced the good batteries with some that were already discharged and compared the results.
logger:
default: error
logs:
rflink: debug
homeassistant.components.rflink: debug
thanks for the tip. will do that when I have time unless it’s got support through Pilight 
I would also prefer using OMG Pilight on Mega instead of RFLink (which needs to be connected over USB) as sometimes, after HA restart, the board is not recognized and I need to reboot.
Having its own IP and with copper connection (even if an ESP board has more computing power, it still doesn’t feel as good as a wired board) makes for a very stable gateway; in fact, I have the OMG RF on Mega with a very old release (more than 2 years) running without problems.
Well, I currently have OMG Pilight @ Sonoff RF Bridge on the ground floor and OMG RF @ Wemos D1 mini on the 1st as a) Pilight does not support all my RF devices yet (Sonoff PIR2) and b) sometimes one of them does not catch the signal (for example, SRFB always catches Open signal from Kerui 026 door sensor, but sometimes misses the Closed signal that is comfortably cached by Wemos) so I’m planning to create some automation to make sure the signal is received anyway.
Apparently there are sometimes issues with duplicate messages when using multiple OMG gateways, but I haven’t investigated it further.
That’s why I don’t really need that copper connection anymore… however, might flash my Mega with OMG at some point to see how it works.
An update:
Played today with this sensor trying to get low battery signal.
It works from 2.83V (fresh batteries) down to 2V (approximately), the screen is almost unusable but it still sends readings. Below 2V it just does not send anything.
However, it does not affect the battery field of the data sent - it’s always 1, like this:
home/OMG_SRFB/PilighttoMQTT {“message”:{“id”:188,“temperature”:23.90,“humidity”:67.00,“battery”:1,“channel”:1},“protocol”:“tfa”,“length”:“188”,“repeats”:2,“status”:2}
It is always accompanied by the following message (with an appropriate ID of course):
home/OMG_SRFB/PilighttoMQTT {“message”:{“id”:155.0,“temperature”:1.4,“humidity”:122.0,“battery”:1.0},“protocol”:“teknihall”,“length”:“155”,“repeats”:2,“status”:2}
Have no idea what it is and if it’s useable at all.
The bottom line is - for some reason (original pilight code, the code used in OMG or it’s my sensors) there is no way to get low battery status, it’s always “OK”.
Could anyone confirm that they are able to get low battery status from R8S sensors?
@PetricaM So far I checked it with R8S and OMG/Pilight and can see no pattern here.
Even if I insert, take out and re-insert freshly charged batteries, I get a different ID every time…
And its ID changes if the batteries are not fully charged, too.
Maybe R8H protocol is very different compared to R8S.
Do you still have the rflink to check with?
of course. just wanted to add some details.
I do. The trouble is RFLink does not support R8S properly, that’s why I discuss it here in OMG thread.
Anyway, I didn’t have time to see changing names and just tried to insert fresh/old batteries into R8H and check logs.
It does not affect device’s name, it’s stable. And I get low battery status when the batteries are a bit discharged.
I’m running HA 0.98.3, your result might be different if your HA is not updated (suspect they made some changes in internal rflink component code in the last 6 months or so).
Wich one of R8H and R8S do you recommend for outddor use? How good is the compatibility with OMG with pilight?
Check the “Devices” link on top right section of the page (it includes all compatible devices).
Only R8S is supported currently with PiLight.
How do you find the range on the R8S? Mine must be broken because I only got 0.5 meters. I am goin to modify it with another transmitter. Hope that helps…
I use R8H as both indoor and outdoor sensors. R8S is more spottable for indoors and I’m hot generally happy with my ones as they keep changing their IDs every time I replace batteries - that’s MADNESS.
Pilight @ OMG kind of works, but currently it’s in a way not the best choice because:
- RF module supports more devices than Pilight
- There is no proper documentation on how to SEND commands via Pilight so you still need RF
- For some devices (including R8S) Pilight support is incomplete - for example, I cannot get “low battery” status, it’s always ok even if the batteries are nearly empty.
- The range of R8S isn’t fantastic, it’s ok… but sometimes my receiver doesn’t receive signal from some of them, and it’s only few meters away - I usually end up replacing their batteries. However, currently my RFLink receiver stopped receiving 2 out of 3 R8S’s signals, but my Pilight receiver got them all - weird… 0.5 meters isn’t right, how’re going to modify it?
I have hacked a Sonoff RF bridge to incorporate Pilight/OMG;
The intent was to use the Digoo R8S;
Unfortunately all R8S units I have ordered so far have failing humidity sensors
They work for a few seconds then return “LL” for humidity which is either out of range humidity (which is not the case here) or failure. If I blow some humid air they eventually show high values but return to “LL” in a matter of seconds.
Unfortunate as temperature works well and communicates easily with Pilight/OMG.
Anyone had the same issue? I don’t mind ordering other units as they are really cheap but don’t want to waste time if this is a design issue and they all fail; if so and you found another working wireless temp/hum sensor, let me know brand/model/source.
The other ones I could find are BT (not supported by Sonoff bridge)
thx
To use BT you just need a barebone ESP32 and you will be able to get all these sensors data:
They are reliable and you have more choice compared to 433mhz temperature and humidity sensors.
Thanks for the reply. Issue with BT seems to be range (or is it?). I read in a few places that range can be around 10-12ft which is way below my requirements. I have 3 floors to cover and dont want to deploy a receiver for each emitter which would essentially defeat the purpose . One Sonoff bridge+R8S works well. Let me know if i am mistaken and what i should expect as far as BT range and through wall/floors performance.
Meanwhile i have disassembled the R8S and the 2wire humidity sensor is really easy to replace so will order new sensors and give it a try.
Thx
Here is the results from my tests without obstacles:
Sounds good, thx for the reply
Can you get a functional signal in the 8meters range? (RSSI -84,-93)
Just to be sure I get this right, can you confirm this is accurate:
purchase hardware (PS: how can I confirm The HM10/11 firmware >= v601 ?)
assemble :
Upload binaries/Install OMG as per documentation.
Verify Broker receives data.
Thx!