Fireangel fire/CO/heat alarm network bridge integration

Feature Requests
82

I won’t be the bridge reporting itself missing. It’ll be the other alarms in the network broadcasting a “D2” message, meaning that they haven’t seen A5B813 for a while.

e.g If you have physical alarms A, B & C.
Remove A from the property, and then you should find B and/or C will periodically report the that A is missing. Useful because it’s ‘actively’ being reported as missing, even when it cannot speak for itself.

Could be I need to add something to the Arduino code to mute this, but I hadn’t noticed it myself.

Are you seeing it because you have added the ID of the pseudo-firmware-device to your dashboard & automations?

I don’t have the pseudo-firmware-device appearing on my dashboard.

In the yaml I shared on github, it’s not in my automations for:

  • Test Fail
  • Removed from Base
  • Device Reported Missing

It only exists in the automations for:

  • Test Pass
  • Emergency
83

Very interested in this and was wondering if anyone in the UK has any spare boards for sale before I place an order.

84

It’s appearing in the state of sensor.fireangeldata i.e. the main sensor that all the template sensors derive their values from. It appears maybe once every hour and only displays for 25 seconds before being overwritten by the next heartBeat. It’s very easy to miss if you are not looking when it does it. I’ve potentially only picked up on it as I am rewritting the way the template sensors work.

This is the state it displays:

{"device":"A5B813", "event":"MISSING", "base":"MISSING", "battery":"MISSING"}

If you switch on History for the sensor you’ll be able to see it in there. Alternatively create a template sensor that only updates when this is the state to avoid sifting through all the heartBeat entries.

85

OK.
How about a modification to the Arduino Firmware so that it only publishes the missing-device-event when:
{Device} != {builtInDeviceID}

86

That would resolve it I’m sure, although I’m not really sure why it’s being reported. From what you’ve said above, it suggests that one of the other alarms in the mesh is reporting that it hasn’t seen the bridge? Therefore, I am wondering if there a problem with my mesh and changing the firmware would simply be masking it, rather than getting to the route of the problem. It would be interesting to know if @Clam58 is still seeing the A5B813 missing message after full reset of all devices (something I can potentially try myself, possibly over the weekend), or if anyone else is seeing this? Is it something you are able to observe on your setup @chopwood ? To be fair, it’s a vey minor “glitch” and doesn’t affect anything functionality-wise. I’m just trying to understand why it’s happening.

87

Only publishing the missing-device-event when: {Device} != {builtInDeviceID}
is the path of least resistance.

To dig deeper into this…

The images below are examples from my notes, when I was trying to figure out the communication.

BaseBattery

Emergency

MissingDevice

Currently a device is reported missing if any message is received where:
Byte(0) = D2
Byte(6,7,8) = DeviceID
Byte(13) = End

Could be that some additional filtering is needed based on the other Bytes.
e.g. D2 also has another purpose, which this project does not support.

A useful test would be to put the bridge into raw mode, and log the output
.
Note the regular message where:
D2 xx xx xx xx xx A5 B8 13 xx xx xx xx 7E

And then perhaps also remove a known device (e.g. DeviceID 112233). And note the message:
D2 xx xx xx xx xx 11 22 33 xx xx xx xx 7E

88

Thanks for that, although that’s getting beyond my comprehension! :laughing:

If you think that {Device} != {builtInDeviceID} is the way forward, then I’ll take your word for it. I was really just wanting to make sure there’s not some underlying issue on my mesh network.

89

Hello,

I’m just wondering if you still have a spare board?
Thanks
Matthias

90

I have 3 spare module parts (non battery type), DM me if you would like them or anyone else for that matter

91

I cant for the life of me see an option to DM you. I guess it might be because I’ve just joined the community. I would be interested in taking any spare parts you have. Any chance you could DM me? Thanks

92

These 3 have now gone to Duskadder

93

Hi all,

I have been reading this thread for the past weeks and decided to buy the fireangel devices and build this project myself as well.
I have built a proto with an arduino UNO and hope to have the arduino nano later this week.

Thank you all very much for your efforts to be able to integrate this system in home assistant and to be able to monitor if the system is running as it should.

Also found the english manual to the Wi-Safe2 Mesh Monitor
EDIT 2-9-2022: unfortunately it was taken offline by fireangel. Luckily I managed to save it as it was still open in my browser, please send me a message when you want it.

94

As I have received most of the gear (except for the PCB) I have built the system on a breadboard.
I immediately got the INIT OK message so the connection to the radio is ok.

During an earlier pairing of the radio with the network, I got a command failed message, but the paired status said paired, so I had assumed everything was working OK. Unfortunately didn’t receive the event when I removed any of the devices from the base so that made me un-pair and pair the radio again. This time got the message the pairing was successful and I now obtained events when removing a device from it’s base. :partying_face:

I did see the missing {“device”: “A5B813”, “event”: “MISSING”, “base”: “MISSING”, “battery”: “MISSING”} message before as well, and I also receive it now.

Additionally I have a WTSL-F-1EU Alarm Control Unit, and currently it is blinking the ! and fire symbols. telling me there is something wrong in the network.

Should’t our project send a heartbeat across the network itself?

@chopwood What project is best to load to gather any data sent over the network? Is it the regular or the debug variant and should I enable or disable the direct mode?

95

Today received my Wi-Safe2 Mesh Monitor, noticed that this application shows a decimal representation of the device ID. Converting that to hex shows the device ID is represented in the wrong order. the first and last 2 letters need to be reversed, so instead of ABCDEF it should be EFCDAB.

Some additional information after investigations:
Protocol analysis I have done so far:
SPI clock on the Wi-Safe2 Mesh Monitor is at 64 kHz

I have a WTSL-F-1EU Alarm control in my network, which communicates using device id: 45:04

1 Like
96

Hi @robertwigley,

Did you get your revamp to a point where you’d be happy to share it?

Thanks

97

Hiya, I am UK based as well. Any chance that you still have a spare board?
Thanks

98

Hi, After a long wait I have received all the parts but when I put it all together I’m having problems with the radio not ready error. This is what I’m getting:

No reply from radio. SPI Buffer= 0000000000000000000000000
Radio not ready - Trying to reset

When I press and hold the pairing button on my radio board I get this:

Expected 467E, but got something else. SPI Buffer= 417E00000000000000000000000

Any ideas how to troubleshoot this?
Thanks

99

Ok, after I have purchased replacement decent quality level converters everything is working fine.
Instead of using template sensor for my alarms I used the mqtt.publish automation service to push the data to my MQTT broker - this way the sensor values are retained between HA updates/restarts:

alias: Fireangel MQTT 2nd Floor
description: Fireangel MQTT 2nd Floor
trigger:
  - platform: state
    entity_id:
      - sensor.fireangeldata
condition:
  - condition: template
    value_template: "{{ states.sensor.fireangeldata.attributes.device=='f90d04'.upper() }}"
action:
  - service: mqtt.publish
    data:
      topic: fireangel/smoke/2nd_floor
      payload_template: "{{ states.sensor.fireangeldata.state }}"
      retain: true
mode: single

After initial series of tests I ended up with this mqtt tree:

Screenshot_20221124_150930
Screenshot_20221124_150930730×190 31.2 KB

Then just added this bit for each alarm to the configuration.yaml

mqtt:
  sensor:
    - name: "FireAngel 2nd Floor Smoke Alarm Event"
      state_topic: "fireangel/smoke/2nd_floor"
      value_template: "{{ value_json.event }} "
      icon: mdi:fire
    - name: "FireAngel 2nd Floor Smoke Alarm Result"
      state_topic: "fireangel/smoke/2nd_floor"
      value_template: "{{ value_json.result }} "
    - name: "FireAngel 2nd Floor Smoke Alarm Base"
      state_topic: "fireangel/smoke/2nd_floor"
      value_template: "{{ value_json.base }} "
    - name: "FireAngel 2nd Floor Smoke Alarm Battery"
      state_topic: "fireangel/smoke/2nd_floor"
      value_template: "{{ value_json.battery }} "
      icon: mdi:battery

Big thanks to Chris for his excellent work!

If anyone is interested I still have 4 spare boards and a couple of level converters.

2 Likes
100

Nive one Andre - if you have two spare boards, I would be happy to take them from you.

Where were you able to get a donor WiSafe2 radio module from? I’m struggling to find anything at a reasonable price…

Thanks.

Edit: Managed to find a WST-630 for sale on ebay - I hope that has the right radio module!

1 Like
101

I just looking in to this at the moment. did you end up going down the ws2mqtt route?