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

AhmadK · July 8, 2019, 3:45pm

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?

PetricaM · July 8, 2019, 4:19pm

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

AhmadK · July 8, 2019, 8:52pm

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…

PetricaM · July 9, 2019, 6:12am

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

PetricaM · July 9, 2019, 6:17am

Also, there are some issues with the protocol being recognized as either Tunex or Xiron. Only the Tunex ID gets updated regularly.

AhmadK · July 9, 2019, 7:11am

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

PetricaM · July 9, 2019, 7:19am

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*

AhmadK · July 17, 2019, 9:36am

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?

PetricaM · July 17, 2019, 11:26am

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

AhmadK · July 17, 2019, 1:27pm

thanks for the tip. will do that when I have time unless it’s got support through Pilight

PetricaM · July 17, 2019, 1:59pm

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.

AhmadK · July 17, 2019, 2:30pm

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.

AhmadK · September 9, 2019, 2:34pm

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.

PetricaM · September 9, 2019, 3:07pm

Maybe R8H protocol is very different compared to R8S.

Do you still have the rflink to check with?

AhmadK · September 9, 2019, 8:00pm

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).

micklacks · October 3, 2019, 9:45am

Wich one of R8H and R8S do you recommend for outddor use? How good is the compatibility with OMG with pilight?

PetricaM · October 3, 2019, 2:51pm

Check the “Devices” link on top right section of the page (it includes all compatible devices).

Only R8S is supported currently with PiLight.

micklacks · October 25, 2019, 2:10pm

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…

AhmadK · October 31, 2019, 10:30pm

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?

123qweasd · March 23, 2020, 2:48am

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