Questions about Netatmo Smoke detector

Add-ons Bindings
1

Hi folks,

do you know if the Smoke detector by Netatmo is compliant with the binding? Is that device enough reliable?

thanks for helping me
Andrea

2

It isn’t supported by the binding at my knowledge.

3

but it seems the device is supported by the public API.

@glhopital do you think this can be integrated into our fantastic binding?

thanks again for your support

Andrea

4

If this is in the public API, yes, it can be integrated but I do not own any of these equipments, so I will not proceed to this update of the binding.

5

Is there anything we can provide so this could be added to the binding?

I no longer trust my zwave smoke detectors. To many disconnections or false alarms. Just don’t find them reliable. And safety should be something to take serious.
I like the products so far from netatmo. So thinking now to buy their smoke detectors.

6

Hello @brononius , IIRW in the current update of the binding, @mdillman has bought a smoke detector and started to implement it but as of today, the API does not seem to deliver any interesting information.

7

They seem to have issues in their backend with data from the Smokedetectors for access with the public API. Their App works very well with them, also their dev-site, only access via publicly available access-scopes is currently crippled.
I received information that they are working on a fix that hopefully should get live the next weeks. Once the data is accessible, I’ll finish integration in the new binding.
See related discussion about the scope-issue on their forum : https://forum.netatmo.com/viewtopic.php?f=5&t=19934

8

It seems the issue is now fixed.

https://forum.netatmo.com/viewtopic.php?f=5&t=19917

How is proceeding the test? shall we try the netatmo smoke detector with OH3?

thanks
Andrea

9

I stopped working on it as it is still dysfunctional. Only webhook seems to provide some basic information (as per the post you quoted), but the main problem is still unsolved (see my post above). Not everybody will be able to use webhooks, so retrieving information in-line to how other modules are polled is IMHO neccessary.

I opened a case with Netatmo-support but they won’t fix the scope discrepancy. What they suggested is to periodically query the past events with /gethomedata.

If you own a smokedetector, open a case and urge them to fix /homestatus. The information is there (and shown on their dev-site), I simply can’t understand why they don’t want to expose it the same way they do for the other modules.

Thanks
-Markus

1 Like
10

oh, it’s a shame :frowning:

I need to substitute my Nest Protect, I’ll go for a Fibaro smoke detector.

11

So good news is: Netatmo support replied to my ticket and they said that they will fix scope discrepancy.

Bad news is: they’ll fix it in the way that they will hide the usefull information that is currently visible via the “try-it” on the dev-website instead of exposing this as well to customers.

1 Like
12

@mdillman

ehm … not sure I’m understanding what should be exposed with “try-it”.

Are we able to see what is present in the API Documentation? I mean what is present in Netatmo Connect | Security API Documentation

hush
smoke
tampered
wifi_status
battery_status
detection_chamber_status
sound_test

and if possible, will be available also in our binding?

thanks man for your support on this :slight_smile:

Andrea

13

another way seems to go through IFTTT:

too complicated?

14

IFTTT is known for an unpredictable latency

1 Like
15

Hi,

any update on this?

Thanks Markus for your support here

Andrea