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 https://discuss.minut.com. 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.
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 minut.com) 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: https://minut.com/developers/#authentication and save your output (example below) from the curl command to point.json in your configuration folder.
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.
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.
Edit:
But as I said, feel free to continue where I left off, the current code is on https://github.com/fredrike/home-assistant/tree/point. I’m still working on binary_sensor integration but other things have higher priority.
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).
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).
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.
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.
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.
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.)
Why not use the battery you get from GET /devices?
Part of my test / play script
`curl -s -H “Authorization: Bearer $MINUTTOKEN” “https://api.minut.com/draft1/devices” | jq -r ‘.devices | map(.description, .battery.percent)’.
Also, for some automation purposes it could be useful to have the time when the last (heartbeat) update was recorded.