RFLink loses entities after HA restart

rontaylor · April 30, 2020, 6:57am

I have just built an RFLink for my HA. I built it using NODO’s circuit board and firmware 48 on an Arduino Mega 2560. USB to NUC.

I have it plugged into mu NUC i3 running HA 0.109.0 (now). It’s a Ubuntu running HA in docker.

I had this going and it was slow to build up the entities I was looking for but eventually did and I added them as entities on a view in my dashboard.
My configs in configuration.yaml for this is simple, straight out of the docs.

rflink:
  port: /dev/ttyACM1
sensor:
# For RFLINK
  - platform: rflink
    automatic_add: true

I had a need to restart HA today and lost the entities

The Red arrows are entities that have not been re-scanned (from what I can tell in the debug logs) but the green one has.

I have run a grep over the log to search for the ID’s but they are not there as yet.
I only have a small aerial at this stage and have ordered a 1/2 wave one for hopefully better reception.

My questions are:

Is this normal or is it a bug?
If it is normal is there a way to stop it losing history?

I am monitoring my Fridge. I have two sensors. One in the main part of the fridge and one in the freezer.
These normally report to a small display using 433MHz. I had them reporting to the entities cards in the top right next to the 2 red arrows.

It was great because I could see the history as well as current temps of both compartments.

Any assistance gratefully received.

francisp · April 30, 2020, 7:08am

The automatic add is great for first discovering them, but once discovered it is better to move them to configuration.yaml (or sensor.yaml, switch.yaml, light.yaml if you have split up your configuration)

Example from my sensor.yaml :

  - platform: rflink
    automatic_add: true
    devices:
      xiron_3201_temp:
        sensor_type: temperature
        aliases:
          - tunex_b201_temp
      xiron_3201_bat:
        sensor_type: battery
        aliases:
          - tunex_b201_bat
      xiron_3201_hum:
        sensor_type: humidity
        aliases:
          - tunex_b201_hum
      xiron_2f02_temp:
        sensor_type: temperature
        aliases:
          - tunex_2f02_temp
      xiron_2f02_bat:
        sensor_type: battery
        aliases:
          - tunex_2f02_bat
      xiron_2f02_hum:
        sensor_type: humidity
        aliases:
          - tunex_2f02_hum          
      xiron_4503_temp:
        sensor_type: temperature
        aliases:
          - tunex_4503_temp
      xiron_4503_bat:
        sensor_type: battery
        aliases:
          - tunex_4503_bat
      xiron_4503_hum:
        sensor_type: humidity
        aliases:
          - tunex_4503_hum

rontaylor · April 30, 2020, 7:15am

Thanks for that.
Yes I can do that but it does not answer my question about the loss of the entity cards.
some 5 minutes after posting this I did get back my freezer and the history was there (apart from when system was restarting etc)

Does having them in the yaml make it any faster or do you just have to be patient?

francisp · April 30, 2020, 7:18am

It keeps them from show ‘entity not available’ until they are found again. And, as in the case of my xiron’s, which send once in a while a message that is misinterpreted, to show up duplicates.

rontaylor · April 30, 2020, 7:20am

Thanks again. That’s a great tip.
cheers

rontaylor · April 30, 2020, 7:56am

I have made the changes to YAML and restarted server. This time it seemed quicker to restore the ones it had found before restart.
It will be interesting to see when the other entities turn up and when I get my 1/2 wavelength aerial for the RFLink what difference that makes. This aerial has a 4.5dbi gain so it should have a better signal and hopefully cull some of the noise.

Found reason for entity not found…
It is a gauge card and currently the value is “unknown” so in this case the yaml coding does not work.
It should come good when it scans it again.

Nothing is ever simple!!

rontaylor · May 4, 2020, 8:44am

I have an interesting problem that I am trying to solve.
It appears that I have a few devices that have rolling ID’s.
By this I mean that the ID for a device might have an ID

inovalley_4e03_temp
If I restart server / reboot NUC or change batteries in the 433 device the ID will go to

inovalley_6b03_temp or something similar.

Some others change digit hex code completely.

This makes it difficult to impossible to try and code them is YAML.

Not sure there is an answer but thought I would ask anyhow.

Any ideas?

Foxxy · May 4, 2020, 9:36am

Changing batteries does change the ID (and channel if multichannel sensor- this 2 last digits in them) but not HA restart…
Best, JR

javicalle · May 5, 2020, 12:56am

As @Foxxy has said, some devices change the ID when you replace the batteries.
If you want to keep historical data, you can define the new ID as an alias of the device configured in HA.
Something like:

sensor:
  - platform: rflink
    automatic_add: false
    devices:
      inovalley_4e03_temp:
        aliases:
          - inovalley_6b03_temp

Regards

rontaylor · May 5, 2020, 8:19am

This is interesting…
This is what I have in my configuration.yaml.

# Sensor section
sensor:
# For RFLINK
  - platform: rflink
    automatic_add: true
    devices:
      inovalley_4e03_temp:
        sensor_type: temperature
        aliases:
          - Fridge-Freezer
      inovalley_9602_temp:
        sensor_type: temperature
        aliases:
          - Fridge-Main

There are two things that I see different.

you have automatic _add as false and I have it as true. Not sure if this makes a difference?
I have looked for the alias names in developer >“States” but cannot locate them. Where to locate them?

What I mainly want to achieve with this is to have an alert if my freezer or fridge go out of limits.
I have set up an Automation to send me a push notification if set temperatures are out of limits for 5 minutes.
This works fine so long as there are constant entities.
I deliberately changed batteries just to see what happened but I am sure that I saw changes when doing restarts & reboots but my memory might be in error.

If I could have an alias that was used in the automation then that would be fine but I cannot see how to do this. I can see how what you suggest would work for history but that’s not my main goal.

The fact that I cannot locate the aliases also puzzles me? I must be looking in the wrong place.

Curious…

Foxxy · May 5, 2020, 9:12am

Aliases must be real alternative names sent by RFLink- eg for temperature sensors some of mine alternate prefixes as xiron/tunex/etc. I do not use auto discovery after initial setup…
Best, JR

rontaylor · May 5, 2020, 9:23am

I did not know that. I just assumed an alias was an alias. I will try and conform to this convention now that I know and see how I go.
Thank You.

rontaylor · May 5, 2020, 7:08pm

Been giving this some thought and I have been thinking about the aliases wrongly.
My original thinking was that I was renaming the entity or giving it an alias. However I think that what you are saying is that the aliases (plural) are previous entity names so that when it changes it associates the aliases with the new one?

Have I got my thinking correct now?

Foxxy · May 5, 2020, 8:00pm

I hope that You have read that: RFLink sensor ?
IMO it explains all rather well
And YES seems that You get closer to the idea- well done!
Best, JR

rontaylor · May 5, 2020, 8:17pm

Yes I had read the RFLink Sensor doco but the subtlety of the aliases did not dawn on me. I some how had a preconceived Idea that I was giving it a friendly name like in other areas of YAML. Silly me.
Thanks for you help and hopefully now on the right track.

This morning I changed the aerial on the NODO RFLing from the little stubby one to a 1/2 wave 4.5dbi aerial.
The error logs seem to contain better data.

2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] received data: 20;82;Ino
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] received data: Valley;ID=4e03;TEMP=80D2
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] received data: ;HUM=00;BAT=LOW;
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] got packet: 20;82;InoValley;ID=4e03;TEMP=80D2;HUM=00;BAT=LOW;
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] decoded packet: {'node': 'gateway', 'protocol': 'inovalley', 'id': '4e03', 'temperature': -21.0, 'temperature_unit': '°C', 'humidity': 0, 'humidity_unit': '%', 'battery': 'low'}
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'inovalley_4e03_temp', 'sensor': 'temperature', 'value': -21.0, 'unit': '°C'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] event of type sensor: {'id': 'inovalley_4e03_temp', 'sensor': 'temperature', 'value': -21.0, 'unit': '°C'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['sensor.inovalley_4e03_temp']
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] passing event to sensor.inovalley_4e03_temp
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'inovalley_4e03_hum', 'sensor': 'humidity', 'value': 0, 'unit': '%'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] event of type sensor: {'id': 'inovalley_4e03_hum', 'sensor': 'humidity', 'value': 0, 'unit': '%'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['sensor.inovalley_4e03_hum']
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] passing event to sensor.inovalley_4e03_hum
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'inovalley_4e03_bat', 'sensor': 'battery', 'value': 'low', 'unit': None}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] event of type sensor: {'id': 'inovalley_4e03_bat', 'sensor': 'battery', 'value': 'low', 'unit': None}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['sensor.inovalley_4e03_bat']
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] passing event to sensor.inovalley_4e03_bat
2020-05-06 06:02:11 DEBUG (MainThread) [rflink.protocol] got event: {'id': 'inovalley_4e03_update_time', 'sensor': 'update_time', 'value': 1588708932, 'unit': 's'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] event of type sensor: {'id': 'inovalley_4e03_update_time', 'sensor': 'update_time', 'value': 1588708932, 'unit': 's'}
2020-05-06 06:02:11 DEBUG (MainThread) [homeassistant.components.rflink] entity_ids: ['sensor.inovalley_4e03_update_time']

Hopefully I can now rely on my automations for out of limits temperature alerts.
Time will tell.

Thanks again for you help.

Update 08:30am 6/5/20

I have just updated to 0.109.4 and my RFLink entities stayed the same. Great.

My config is now

# For RFLINK
  - platform: rflink
    automatic_add: true
    devices:
      inovalley_4e03_temp:
        sensor_type: temperature
        aliases:
          - inovalley_b603_temp
      inovalley_1102_temp:
        sensor_type: temperature
        aliases:
          - inovalley_9602_temp
      fineoffset_0079_temp:
        sensor_type: temperature
        aliases:
          - fineoffset_0029_temp
#
#

Cheers
RT

Foxxy · May 6, 2020, 10:48am

Sounds good that it is sorted out
Best, JR