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*
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.
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:
It is always accompanied by the following message (with an appropriate ID of course):
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).