No arguments with you there, but absent a published API, there are no guidelines other than our intuition about what amount of polling is reasonable. The current plugin defaults to two minutes, but allows you to set it as low as one minute. Even polling every minute might be considered excessive, but I have no way of knowing (and I certainly hope not). Pounding their servers with polling is a sure way to get them to cut off either individual users or all plugin users, so we have to be extremely cautious to avoid creating unreasonable situations. Your concern is another reason to wait for the official API release, wherein I’m sure they will tell us what limits we have to comply with.
And this is a good place to repeat the caveat that the plugin is licensed under terms that places any and all risks, including a Vera not triggering on a smoke or CO alarm (or doing so with a delay), outside of the developer. This is serious stuff, and no one should rely on this plugin when it comes to a person’s health and safety.
[quote=“watou, post:21, topic:177263”]And this is a good place to repeat the caveat that the plugin is licensed under terms that places any and all risks, including a Vera not triggering on a smoke or CO alarm (or doing so with a delay), outside of the developer. This is serious stuff, and no one should rely on this plugin when it comes to a person’s health and safety.
watou[/quote]
I completely agree with this. When it comes to alerting the user, I would rather have multiple of these and let them handle the local alerts (as they should anyways). I dont’ think anyone should use this as a way to notify them of a fire through vera. The devices themselves should handle this quite fine and though it will mean multiple points of access to control them, I’m personally fine with that.
The functions I’m looking for are the extra sensors that I hope the API will open up such as the motion sensor and hopefully light sensor as well as maybe being able to control the led light on it through vera. Stuff like that.
Extremely true. I wouldn’t want to mess with the communications path. They’ve already got a mechanism to alert. My main interest is in more general responses from the vera. e.g. turning lights on, turning furnace off. etc.
I’m more than happy to help test whenever appropriate. I already have your Nest plugin for the thermostat and a couple of protects set up.
While the google deal may have delayed things, I’d hope it wouldn’t change their intent. They’ve always been pretty good about opening APIs in the most part.
From a functionality perspective, I’m not sure you need to go near the alarming, smoke or CO2 capabilities at all as the nest app already does a good job on that front. What would be really interesting is being able to get the other sensors to show up in Vera, including motion, temperature and light. Being able to use those as triggers for other things would be fantastic.
Just bought 4 Nest Protect and the Vera Lite controller with some extra sensors. I believe I have read somewhere that the API?s for the Protect have been published by Nest. Are there any efforts to include the Protect in the Vera environment. That would be a nice benefit and the reason why I bought the Vera and no other controller
I am thinking it might now make sense to add the Protect to the existing Nest plugin. This would surface a new SmokeSensor and a new COSensor device (standard Vera device types) for each Protect it found. Any feedback on this idea?
That’d be great. I’ve got some protects that I would love to integrate into vera. Would it require having a nest thermostat? I don’t have the nest thermostat and I’d prefer to keep the one I have.
I think the only requirement would be that you have an account at nest.com with your device(s) registered there. I will need help testing the new code for users like you who only have Protect(s) and not thermostat(s). I expect to have something to test in the next two weeks.
I think the only requirement would be that you have an account at nest.com with your device(s) registered there. I will need help testing the new code for users like you who only have Protect(s) and not thermostat(s). I expect to have something to test in the next two weeks.[/quote]
ditto. I have Nest protects but no thermostats. I’ll be happy to test.
Regarding extending the Nest plugin to support the Protect, I want to get the battery level as meaningful as possible, so one can learn from Vera when it’s time to replace the batteries. Of course, the native app will give you warnings six and then three months before the batteries are too weak, but I want to show battery level properly in Vera.
Can anyone here help me with what would be the best theory for the meaning of a battery_level of 5304 in a battery-powered Nest Protect?
Here’s my theory: Since the wired version of the Protect needs 3 L91 lithium AA batteries as a backup, and the battery-powered version needs 6 of those, it makes me think that the 6 batteries are two sets of three in parallel, giving a voltage level that is three times the voltage of a single lithium AA. Since Lithium AA batteries have an unloaded voltage of 1.8, 3 * 1.8 is 5.4. So if the Protect is reporting its battery level in millivolts, then it’s conceivable that my Protect, with two sets of three lithium batteries in parallel, is currently providing 5.304 volts. So if this is true, all I need to do is determine what the minimum usable voltage level is, and this will define the scale for reporting in Vera.
For testing, I’ve added support for just the smoke detector part of the Nest Protect to the existing Nest plugin. It uses the existing service and device definition files for smoke detectors that I found on my Vera. This has the benefit of working wherever there is existing support for smoke detectors in Vera (and mobile apps) without requiring code to be changed to support a new service or device type. The downside is that there is no pretty Nest icon, only the default one.
While there is a subcategory defined for CO detectors (5), I did not find XML or JSON files on my Vera for them, so I would like feedback on this before I add an additional device to support the CO detector.
So I’m looking for testers. I haven’t blown smoke at my Protect, so if anyone wants to test the attached file, I would appreciate it.
To install this alpha version:
[ul][li]Install the current Nest v1.6 plugin if not already installed, and set your username and password so it is logging into nest.com successfully.[/li]
[li]Download the attached I_Nest1.xml file, and go to Apps → Develop Apps → Luup files, Choose the file, check the “Restart Luup after upload” box, and press GO.[/li][/ul]
Your Vera will restart twice; once to load the newly uploaded file, and again when new Nest device(s) are discovered and added. The log will report the plugin version as 1.7, but it’s not yet the real 1.7 version until the new update is in the app store.
Caveats:
[ul][li]The plugin will only trigger that smoke was detected after the next polling cycle, up to two minutes by default.[/li]
[li]The smoke detector support is not to be relied upon for any purpose that effects the life or health of anyone – the standard disclaimers against all liability in the current license are also in effect.[/li]
[li]This support does not use the new official Nest API; that will have to wait until the official API includes more features.[/li]
[li]I see no way to receive notifications from the passive infrared sensor in the Protect to use as a motion sensor.[/li]
[li]I have not tested against a nest.com account that does not also have a thermostat device but I don’t (yet) know of a reason why it shouldn’t work.[/li][/ul]
Install was clean, no problems and detected/added my 6 protects almost immediately. Trigger info is present within scenes and was able to quickly associate (assign name/room) the devices based on the plug-in ‘Altid’ and Nest’s (website) technical data (‘802.15.4mac’). Battery levels are displaying and readings are between 90-93%.
I’m 110% sure my wife will be pissed at me for testing using smoke, not sure if manually testing the device yields the same results. However, how are we sure these detectors even work …
[quote=“CudaNet, post:39, topic:177263”]Install was clean, no problems and detected/added my 6 protects almost immediately. Trigger info is present within scenes and was able to quickly associate (assign name/room) the devices based on the plug-in ‘Altid’ and Nest’s (website) technical data (‘802.15.4mac’). Battery levels are displaying and readings are between 90-93%.
I’m 110% sure my wife will be pissed at me for testing using smoke, not sure if manually testing the device yields the same results. However, how are we sure these detectors even work …[/quote]
Good to hear. At some point I had set the “description” field for my Protect as “Upstairs” and that came through as the Vera device name. I was hoping that at least something meaningful would be provided when the user hadn’t set the name explicitly online.
Sorry to burden you (and your family) with empirical smoke testing, if you choose to, but at least I can say that I’m pretty sure the trigger will fire within two minutes.
While I’m thinking of it, the Protect battery level is currently being shown between the range of 4200 and 5400, which I am interpreting to be millivolts as supplied by lithium AA batteries. I guessed at 4200 (a low battery being 1.4 volts), but I don’t know. I’m still hoping someone chimes in about my battery hypothesis above, and what a need-to-change-the-batteries condition would be in terms of voltage. It’s all guessing at the moment.
Thanks, and please let me know if you get a chance to actually create a smoke condition. I doubt that the test mode will register as actual smoke.
