DIGOO DG-R8S 433MHZ battery operated temperature and humidity sensor with embedded display

Compatible devices
1

Hello,

For information this cheap temperature and humidity sensor (DIGOO DG-R8S) is compatible with OMG (use ZgatewayPilight):

Affiliated link

Here is an example of what you can get from it:

OpenMQTTGateway_Pilight_Digoo-DG-R8S
OpenMQTTGateway_Pilight_Digoo-DG-R8S1197×739 41.2 KB

The good message is from protocol “tfa”

2

Hi Florian,

I own several Digoo DG-R8H sensors that are supported by RFLink.
Do you think it is possible that OMG might handle them as well?
I’m not familiar with ZgatewayPilight and currently have my OMG@Wemos D1 mini configured as ZgatewayRF only.

3

Hi,

Yes I think it is possible, and I will be interested by your tests. If you can try to put ZgatewayPilight to your board and see if you pick up the data it could be great.

4

What needs to be done exactly? I can see nothing about it on Wiki (or just don’t know where to look)

5

Yes it is on the v0.9beta, you need to uncomment ZgatewayPilight and comment the other gateways.

6

If I just uncomment ZgatewayPilight and comment the other gateways (including ZgatewayRF) and leave receiver/transmitter connected as for ZgatewayRF, I can see nothing from OMG in mqtt logs apart from online/offline/sys messages.
No meaningful output in serial monitor as previously mentioned :frowning:
Anything else I can try?

7

Did you try to press some remote control buttons or to make closer your weather stations?
Could you post a dedicated topic maybe so as to don’t go off topic for this one.

8

Hello Florian,

Could you mention your build environment for PiLight?

It doesn’t compile for Arduino either UNO or Mega (but compiling works for ESP) on fresh Arduino 1.8.8. It throws the following error (and I can’t find “functional” or “functional.h” file in any of the ESP libraries).

Thanks

Documents\arduino-1.8.8\libraries\ESPiLight\src/ESPiLight.h:23:22: fatal error: functional: No such file or directory

9

Hello @PetricaM ,

I don’t think it will work with Uno, regarding MEGA I didn’t tested it yet.
Maybe we should add some warnings about that in the wiki.

After a first look, there is some work to make it compatible but it could be very interesting.

10

I can do hardware testing (mostly during weekends). Not too much of codding, though :slight_smile:

By the way, I did manage to compile OMG RF for Nano (similar to UNO in terms of processing power) & Ethernet Shield (with “EtherCard.h”) in the link below (actually it is not using W5100 :frowning: so the compile process was not really smooth as I had to comment out some components which I din’t fully understood) but the board kept restarting. With only a fraction of the size of the larger boards, it is quite interesting; however, the ethernet shield makes it problematic.

Regards

11

Thanks for proposing! This is nice :slight_smile:

I’m going to order one ENC28J60, I’m quite interested in making OMG compatible with nano (seems like a challenge for me) :slight_smile: In a separate thread :wink:

12

I’ve added a compatibility matrix for the boards hbelow:

13

Can I use sonoff RF ?

14

Yes if you follow this tutorial:

15

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?

16

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.

17

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?

18

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 :slight_smile:

19

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…

20

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: '%'