Integration with Minut Point?

Is there anyone more on the forum whom is using the device Point created by the Swedish startup Minut?

The device is really great, has a couple of different sensors (temp, sound, humidity, etc.). The app together with the device also has really good presence detection, which would be nice to integrate into HASS.

They also have a API which could be utilized in order to integrate it into HASS.

1 Like

Sorry to bring up and old post, but I’ve recently moved to hassio and have two points that I would like to get integrated in some way. Has anyone done any work on this? I am assuming not based on limited google results…

I have a little dev experience, so might take a pop at something if nothing exists, but not sure if I will get far.

To use the point API you need to get a client id and secret by contact minut. You then have to make a client app for OAUTH with point before you can use the various api calls. Is there anything in existence for a similar setup I could use as a reference?


I’m still interested in this since a have a Point device. I’ve basic python skills and have tried working with some APIs so I can help out. At least on testing it.

There should probably be people that have tried the API with Python on I did a quick search and did also find this:

Thanks Ola, I’ll take a look as and when I can but won’t promise anything. With point v2 on the way as well I am wondering if things will change with the API.

I think this is closest to what we would need:

Nice simple node implementation; just need to scrub up on my javascript to be able port things over to python…

Sounds good! With the point-cli it’s possible to do something really sinmple by running this at a set intervall, fetch and import the data to home assistant. Will take a look at this in the mean time.

I’m in the process of implementing support for Minut Point into hass but have some design “issues” that I like to discuss.

The most basic function would be to iterate trough all the Points associated with your login and create sensors for each of them (temperature, humidity, sound level etc.).

The other interesting part would be to subscribe to the web-hooks (push notifications) from your Points and enable hass to automate based on the different hooks. The question is how we should implement this, should it be implemented as a binary sensor (just like Nest currently is implemented) or should it be implemented more like an Alarm (like Verisure).
What do you think?

I’ll start with the sensor part and we’ll see what happens with the push part…


There is actually nothing saying that it should be one or the other… there is of course an alternative to do both.

However I would personally prioritize making the Minut Point available as an binary sensor, since this gives us the full capabilities of the HASS-automation stack. Alarm for me seems to require alot more customization for each inividual action.
I also feel that the binary sensor is much more future-proof within the HASS development project as a whole. With Alarm being more of a niche.

Either way great iniative with this work, and I will support & subscribe this thread and follow your progress. :slight_smile:

Ok here we go…

This is the first very basic implementation of Point. It currently only support sensors, neither events (alerts from the Point-device) that will be implemented as a binary sensor nor authentication setup (I’m waiting for tokens and reply from is implemented (but it is on the way).

To test it out you need to do the authentication magic your self, follow the guide here: and save your output (example below) from the curl command to point.json in your configuration folder.

 "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiI1NWE1MDQxYjkwODUyNGZkMGZmZTJiOGMiLCJyb2xlcyI6WyJkZW1vLXVzZXIiXSwib3JnSWQiOiJtaW51dCIsInNjb3BlIjoiIiwiaWF0IjoxNDkwNjM2OTQyLCJleHAiOjE0OTA2NDA1NDIsImlzcyI6Ik1pbnV0LCBJbmMuIn0.KTZPwfOwYTJlZRxNctJDHSN2QeHG7JE2wLYlOsXymmQ",
 "refresh_token": "5QwnZ2qq47gLj6A0E86Ejgmy7EAkd3YI",
 "expires_in": "3600",
 "user_id": "55a5041b908524fd0ffe2b8c",
 "token_type": "Bearer"

Also, add the lines below to your configuration.yaml:

  client_id: 55e77060be6dcf4b
  client_secret: dd3c962b7e8853f630145c5093d85d75 

Extract this file to your configuration folder and restart home-assistant, now 4 new sensors per Point (temp, humidity, sound-level, pressure) should show up.


Do I need/want to contact them to create a new API client application?

No, you just need to follow my guide.

I’ve been in contact with Minut but never got a straight answer on how to integrate the auth process smoothly I to home assistant.

I’ve been using the code above since I posted it and it is stable. I’ve also started building support for events but haven’t had time to finish that.

It just seemed strange to approve Marcus API test to get the details…

Btw. You don’t need to start a local host server, as described on the Minut website.

1 Like

Yes, that’s strange…

Feel free to contact them and get an api key. I’m not sure if we could use the same key for the integration or if we need one key per user.

I think that we need to specify an url for the token to Minut and I don’t know exactly how that could be generalized from the home assistant side.

But as I said, feel free to continue where I left off, the current code is on I’m still working on binary_sensor integration but other things have higher priority.

1 Like

Anyone any luck in trying to integrate the points with the new webhooks feature announced in HA 0.80?

1 Like

It looks pretty straightforward so I might give it a try next week.

1 Like

I’ve submitted a WIP pull-request to github now.

It have support for the integration flow and handles authentication fine. I’ve not integrated the webhooks part but it is pretty straightforward. The question is if we need binary_sensors for everything the point can alarm on or if it is enough to fire an event and from that event build actions (I guess the interested could build template binary sensors from the event).

This is the “most common” events according to

Type Description
alarm_heard An alarm sound was recognised
short_button_press The button on Point was pressed
temperature_high Temperature is higher than the configured threshold
temperature_low Temperature is lower than the configured threshold
temperature_dropped_normal Temperature is back down to normal
temperature_risen_normal Temperature is back up to normal
humidity_high Humidity is higher than the configured threshold
humidity_low Humidity is lower than the configured threshold
humidity_dropped_normal Humidity is back down to normal
humidity_risen_normal Humidity is back up to normal
device_offline Device went offline
device_online Device went online
tamper Point was removed from or put back on its mounting plate
battery_low The batteries need to be replaced
activity_detected Point has detected activity

Yes, those are the events listed on the introduction page… But I guess that we want some other events as well, like the ones for audio. The list of events in the API is better. (Mind that it is not complete! There are also some setup and welcome events.)

Also, worth knowing is that the wildcard (*) for setting up a webhook firing at every event does not work (and that it is unknown if the wildcard will fire for all currently available events or for all events (events currently available and events added in the future).

1 Like

I’v implemented support for the following events:

    'battery':       # On means low, Off means normal
    ('battery_low', ''),
    'cold':          # On means cold, Off means normal
    ('temperature_low', 'temperature_risen_normal'),
    'connectivity':  # On means connected, Off means disconnected
    ('device_online', 'device_offline'),
    'dry':           # On means too dry, Off means normal
    ('humidity_low', 'humidity_risen_normal'),
    'heat':          # On means hot, Off means normal
    ('temperature_high', 'temperature_dropped_normal'),
    'moisture':      # On means wet, Off means dry
    ('humidity_high', 'humidity_dropped_normal'),
    'sound':         # On means sound detected, Off means no sound (clear)
    ('avg_sound_high', 'sound_level_dropped_normal'),

@gaffe, let me know if you think I’ve missed something as I’m wrapping up the integration over the next 24h.

1 Like

You may want to include the events for tamper and short_button_press as these are typical events users will generate. (And the button can then be more useful than just for notifying your phone app.)

I have not been able to provoke a point generating activity events… but I hope that we will get the activity_detected events in the near future so having them prepared could be nice.

Great work! Wrap it up!

This is the currently running Point integration.

I’m not sure exactly on how to integrate the short_button_press and activity_detected as a binary sensor (the sensor will just be a toggle so it will go active and then go off again) or I skip it as a sensor and you just have to build an automation from the webhook.

Edit: Here is my PR for the documentation, would love some help in describing what the Point is:

Yes, correct. There would be little use in sensors for the the press, tampering and activity. Does not the battery_low event fall in the same category? There is no ‘battery_ok’ event, so once fired it will never reset. Myself, I’ll probably track them using webhooks.

A (normal) sensor for the battery.percent? (I don’t think the battery.voltage will be of much use.)