Calling all Developers! Need custom DTH for Fibaro 01 smoke sensor (your time compensated)

Hi There Dev community,

I have spent most of my Christmas break trying to figure out if getting the Fibaro FGSS-001 smoke detector working on ST is possible. Because of UK building regulations I have to use the 001 in certain locations (the main escape route from the house) because they must be wired to a permanent supply. So far I have had little success.

If there are any Devs out there who like a challenge and would be interested in taking a look at this please PM me. I’m sure we could agree some form of compensation :wink:

(P.S. if this post breaks forum rules I humbly apologise!)

1 Like

I know you’ve already seen this, but for any devs who might be interested in taking on this project, here’s what support had to say:

What intrigues me is in another thread Tyler mentions Fibaro asked ST not to support the FGSS001… If it is a ZWave device that complies to the standard (and it has an implementation conformance cert surely it should work with ST with the right code?

All I really need is to be able to do is set the preferences (like sensitivity) and get the reading from the Temp sensor. The wired connection to my house alarm will take care of alarm states.

The problem is that in order to be certified as a controller, as SmartThings is, all it has to do is to be able to establish the network and then send “basic” commands, and basic has a very specific meaning in the Z wave context.

Basic here means essentially on/off/dim.

Smartthings can do that.

The problem with the fIbaro 01 sensor is that it is using some advanced features, in particular multiple end points. Smartthings doesn’t handle multiple end point Devices very well in the official features. And didn’t handle them at all when it first launched.

For example, if you add the enerwave SC7 seven button light switch to SmartThings, it will only see the first button.

In that case, community developers have been able to create code which works OK.

Another example is the Aeon power strip, which has six outlets. Again, if you just add it to SmartThings, you only see a single on/off option. Community developers have created device type handlers which assign a virtual switch to each of the six outlets so you can control them independently.

There are other examples as well. I haven’t looked At any of the details for the two smoke sensors, but my understanding from glancing over the staff responses is that the device will require some code for multiple endpoints.

Speaking just for myself, that’s something I might do for a light switch, but I would never do it for a smoke sensor. Which might be where a Fibaro response came from.

Why? Because once you go to custom code, that device cannot run locally at the present time. That means if the Internet goes down, that device won’t work as expected in terms of communicating with SmartThings. Your Smartthings hub will no longer be able to understand its messages. And of course a fire is exactly the kind of a situation when you might start losing Internet or mains power.

Most customers who buy SmartThings products have no idea that this forum exists, and no awareness of the issues with local versus cloud-based processing. Imagine if they successfully set up a simple siren and lights alert notification when the smoke sensor detected something with no awareness that the smoke sensor alert would never be received by the local SmartThings hub if the Internet was off. :scream:

SmartThings has disclaimers that it should never be used for emergency situations, but again, but most people never see those.

I don’t know for sure that Fibaro said “If you can’t support it locally, don’t support it officially” but I think it would be a reasonable position for the manufacturer of a smoke sensor to take.

Again, all of this (except for the challenges involved with multi endpoint devices in a SmartThings platform) is speculation on my part.

1 Like

Hi JD,

Thanks for the reply. That does makes sense but then wouldn’t the same logic apply for the 002 smoke sensor which has essentially the same (although slightly extended) command set? That would be at even bigger risk from a comms failure as the 001 at least has a simple N/C relay for connecting to an alarm system which is switched on smoke detection irrespective of wether the detector is connected to a ZWave network or not.

This is what I will be doing for building regs purposes as under latest regs smoke detectors can be powered via low voltage as long as it is derived from a mains feed and is battery backed up - which my alarm system is :slight_smile:. I guess I could use a 002 and hard wire the battery terminals from my alarm as the 002 uses the same 12V batteries as the 001. But I couldn’t have a wired connection straight back to my alarm - it would need to be via a relay triggered by the ST hub - which I think is less robust than directly hard wired to my house alarm.

My understanding of the Fibaro detectors is once the preferences are set it will operate as an alarm with or without a ZWave network/controller - certainly when I first got them I powered them up and smoke tested them before they were connected to the controller and they went off.

Yes, all the residential networked smoke sensors, either in UK or the US, also function exactly the same as the nonnetworked sensors in that they have their own internal siren. So someone nearby should hear the alarm. The issue is only if the customer is expecting something more from a networked device, and relying on that feature.

I don’t know what the exact differences are between 01 and 02, but obviously there are differences.

02 is on the official “works with SmartThings” list in the UK, which should mean there’s at least a chance that it can run locally. I don’t know if it actually does.

I have ordered a Zipato Zipabox - going to give that a try as it can also be a proper house alarm which also needs replacing since our renovation work.

3rd time lucky as I started with the Fibaro HC2 but it had a horrible interface!