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

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

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

#22

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

#23

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*