[ALPHA RELEASE] Unofficial Notion drivers for home sensors

If you are not familiar with Notion, more can be found at https://getnotion.com/

NOTE: This is a pretty early alpha set of completely unofficial drivers in supporting Notion. This was written without official documentation from Notion.

This is my first time writing anything in groovy much less anything for HE, so there may be bugs and other unexpected behavior. Contributions for improvement are welcome!

In my personal setup, I only have a few of these Notion sensors (Gen 3) and use them only for leak and temperature detection. Thus, my testing to date has been very limited. Again, contributions are welcome. I have attempted to include support for:

  • temperature
  • leak (water)
  • battery (see below)
  • presence of the sensor
  • smoke alarm (see below)
  • door, sliding door, safe, garage door and windows (horizontal & vertical)

And some sensor level info:

  • signal strength
  • last reported time
  • firmware version
  • hardware version

Instructions:
Both the main driver and the child driver must be installed. This parent Notion Driver will use the Notion Sensor child driver to create the discovered sensor devices and update data accordingly.

  1. Login to your Hubitat and go to Advanced -> Drivers Code
  2. Choose new driver to add this driver and then do it again for the child Notion Sensor driver
  3. Go to Devices -> Add Virtual Device - give it a name and select this driver
  4. Save and configure

Downloads:

Note regarding battery: Notion battery levels are named: high, medium, low, etc... so I have provided the following Notion to Hubitat Battery Levels: high=100, medium=50, low=15, critical=1, -not reported-=0 mapping. If you are wondering why the number seem static and then jumps, this is why.

Note regarding smoke alarm: the sensors do not actually have a smoke alarm. Instructions are to place the sensor near an actual smoke alarm. I have neither tried nor tested this and my assumption is that this will sense the audible alarm and thus trigger the status.

Again, my testing to date has been very limited to just a subset of the sensor capabilities. Contributions are welcome!

2 Likes

Seems like a nice multi sensor, but a bit pricey and requires a call to the cloud to integrate with Hubitat?

Yes. Very fair assessment. They are functional and relatively easy to use, it could be good for the non-technical folks. Probably not the type of thing an existing HE user would purchase.

Most of my network is z-wave and just a few zigbee. As a personal preference, I would much prefer to stick with those on my home network without the cloud dependency. I ended up with a starter set of these and found myself a bit frustrated that there was no obvious way to get them integrated with my Hubitat... so, I created this to at least have some common view into my HE.

1 Like

This is great! I got a few Notion sensors from my home insurance company and been looking to integrate them and ditch the separate app.

I've been intrigued by Notion since their Kickstarter days but never pulled the trigger because of the cloud dependency. My main use would be to get notified if any window/door 'moved'. Plenty of ways to know if they are open/closed but to know when one has 'moved' would be awesome.

Couple of questions for those that have used the sensors...

  • How fast do they report? Potentially all the way to HE?
  • Do you have a screenshot of the device created in HE, showing the 'Current Stats'?
  • Any known issues setting up the hub with Google/Nest Wi-fi? Wish they had a forum! lol

Thanks and great work on this driver!

Interesting use case. I do not have any experience with using the sensors that way, but I do see on the website that they sell "notion magnets" which I imagine would help with the accuracy.

Right now, this driver may not be the best for this purpose but, it does have me thinking about offering a current state indicator to expose if the state has changed since the last polling event. It looks like cloud data contains a time stamp as to when the task itself had last reported a change which might be valuable to expose as well. I would bet that adding those things would allow for your "moved" to be possible. However, if you want to know the instant that the event occurred, this may not be a great way to do it, as the speed of reporting alerts on this way will be limited to the polling vs. a z-wave contact sensor publishing the event as it happens or even using Notion's mobile app to receive a push notification.

The sensors seem to report up to the cloud very quickly - for me, I see updates available via the cloud api almost right away. I'm not sure the exact frequency, but there is little delay.

This HE driver is currently using polling. I did not see an obvious way to subscribe to published events. The polling is mostly configurable. It defaults to 10 minutes, but can be switched to every 1 minute via a simple drop down preference in the parent driver.

The mobile app can receive push notifications, which might be the absolute fastest way to be notified with a door or windows has opened.

This is a screenshot of a parent device (fake data):


This is a screenshot of a child device - one is dynamically created per sensor from the parent:

The values in Current Status will depend on how the sensor is configured, some are common while others are specific. For example, my sensors are tasked for temperature and leak. If yours were tasked as a door then there would be a "contact : closed" or open. If you use the smoke alarm alerting, then it would be "smoke : clear" or detected.

sorry, I have no experience with that one.

Awesome info, thanks! I found a hub with 2 sensors (gen 3) on eBay for $40 shipped, so I pulled the trigger and have them on the way.

Sounds like a plan. :wink:

@bptworld - I found a little bit of time and updated the drivers. The current states now include two additional attributes for each task (capability) type. essentially:

  • 'capabilty attribute'_did_change : true or false
  • 'capabilty attribute'_change_last_reported_at : (date)

...More importantly, say a door opens and closes in between polling. the state itself would always say closed, but the last reported at would update with the time of the most recent event and, if that time has changed since the last polling, the did_change will be true until the next polling where the last_reported_at has not changed.

Example:

  • temperature : 73.2285308837890616
  • temperature_change_last_reported_at : 2021-02-22T02:01:01.204Z
  • temperature_did_change : true
  • water : dry
  • water_change_last_reported_at : 2019-12-19T00:11:10.106Z
  • water_did_change : false

That should be enough to create some pretty advanced rules for trigger on all sorts of events.

1 Like

Looks good. Hopefully I'll get to test by the end of the week.