Yes if you follow this tutorial:
DIGOO DG-R8S 433MHZ battery operated temperature and humidity sensor with embedded display
I’m also interested in getting the DG-R8H working with OMG running ZgatewayPilight. I have a D1 mini setup and running the latest beta and have two DG-R8Ss working, but unfortunately I’m not seeing anything when trying the R8H. Its LED will light up indicating a transmission but nothing on OMG. Any troubleshooting ideas where I can start?
I think it is more that the DG-R8H is not yet supported by pilight.
I have one into the boat to my house. I will try to integrate it when received.
I currently use 3 of them with Pilight module @ Sonoff RF Bridge and it works fairly well.
@1technophile the only annoying thing is that every time I change batteries the sensors’ id changes so I need to change it in the code - VERY inconvenient.
Do you know if we can do anything with it?
Hi,
I don’t know if you’re using the same unit as me (R8H). In my case (only tested with RFLink) the change of ID occurs a little different than you described: it migrates to another one when the battery gets low (putting a new battery sends the original ID again). In fact, there’s something good about as I can use this behavior to monitor battery level when it starts sending the different ID 
I use both and with both I have a similar pattern (R8H through RFLink and R8S through OMG Pilight)
So how exactly do you get that the batteries are low? Actually, my R8H repost their battery status, but I have automation that check when the last reading arrived and if it’s more than a set threshold, warns me.
Anyway, as the ID doesn’t get back after recharging batteries, I find it quite annoying to tweak my code all the time, it’s just not sustainable…
When battery is normal, the sensor uses tunex_7f01; however, when the battery is low, ID starts oscillating between tunex_7f01 and tunex_7f02 and, if almost discharged, only tunex_7f02 will appear.
HA template for battery sensor is defined as following. Automation can be set with numeric_state below 100.
fridge_sensor_battery:
friendly_name: Fridge Sensor Battery
value_template: >
{% if is_state('sensor.tunex_7f01_bat', 'unknown') or is_state('sensor.tunex_7f01_bat','low') or is_state('sensor.tunex_7f02_bat','low') %}
0
{% elif is_state('sensor.tunex_7f01_bat','ok')%}
100
{% else %}
50
{% endif %}
icon_template: >
{% if is_state('sensor.tunex_7f01_bat', 'unknown') or is_state('sensor.tunex_7f01_bat','low') or is_state('sensor.tunex_7f02_bat','low') %}
mdi:battery-charging-wireless-outline
{% else %}
mdi:battery
{% endif %}
unit_of_measurement: '%'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: debugthanks 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.