I too hope this is the last that needs to be said on this subject, and that this thread can return to discussion of the Nest plugin.
Thank you for apologizing for the way in which you handled your irritation, and for retracting your assertion that 20% of my plugin is copied from yours, thereby undoing the reputational harm of your original messages. As I said immediately, I regret not having acknowledged that your plugin was one of the ones that helped me understand how to write plugins, and that your short shell script to work around the plugin deployment problem was hard earned and you rightly expected attribution for it. I will say, however, that it’s a stretch too far to say that the round() or (de)localizeTemp functions are copied from your code – they are in fact different in non-cosmetic ways, despite the names being the same. After all, there are only so many ways to round numbers or convert between Fahrenheit and Celsius. Likewise, string constants for thermostat service IDs is also a bit of a stretch. Nonetheless, your plugin was indeed educational, and I’m glad you made it open source so new developers like me could benefit from your efforts. As for the deepToString helper function, my code doesn’t use it, and it is one of those “learning Lua” things that seems far outside the concern of anyone regarding copyright. Regardless, I will remove it from my plugin, and credit you for having solved the module deployment problem. Those kinds of issues are really very annoying.
I understand software licenses pretty well. Because I believed that I did not reuse your copyrighted work, it did not occur to me to attach your copyright to my work. In the case of the decompressScript, I now believe that this was your hard-earned work and you certainly deserve attribution for it. I will make changes to my I_Nest.xml and README.md to reflect this attribution.
As we shared in private messages, we both acknowledge that we both made mistakes. I hope others can learn from this stretch of messages in the future.
I just noticed that version 0.9 of the plugin is now available at apps.mios.com. Please update to it when you can and let me know if you see anything strange. It should only differ from 0.8 in that there should be less log output (no setting of variables that haven’t changed – thanks guessed for that suggestion), the LastUpdate and BatteryDate variables for the thermostat and humidistat devices reflect the last time the thermostat connected to nest.com, and the LastUpdate variable for the location device should be the timestamp value from nest.com for that location.
Also, if anyone has a 2nd generation Nest thermostat and uses it to control humidity, I would like thoughts on the best way to expose that functionality in the humidistat device. (I only have a 1st gen Nest and no way to control humidity in my HVAC system.)
I have updated and see a minor problem. I doubt that this is related to the new version. It’s probably something I didn’t notice in the previous versions.
The Nest related images/icons that appear in the Overview pane do not appear. If I look at the source for these images I see something like:
[quote=“knewmania, post:143, topic:171456”]I have updated and see a minor problem. I doubt that this is related to the new version. It’s probably something I didn’t notice in the previous versions.
The Nest related images/icons that appear in the Overview pane do not appear.[/quote]
Thanks, I noticed that, too. My guess was that, since the Overview pane says it’s beta, that this was a known issue when device icons are specified with the full URL instead of being relative to the normal icons path on your Vera. I tried (abortively) to install the icons with the plugin in the 0.5 release, but since it didn’t go according to plan, I reverted back to the approach taken in some other plugins where the icons are hosted elsewhere. Ideally the icons would be installed with the plugin.
I host the icons on Vera … but it’s a pain with the App store publisher.
I have the icon files in the same directory as all of the Vera Icons:
/www/cmh/skins/default/icons
But you have to remember the following every time you create a new version. For each icon in your file list:
[quote=“RichardTSchaefer, post:145, topic:171456”]I host the icons on Vera … but it’s a pain with the App store publisher.
I have the icon files in the same directory as all of the Vera Icons:
/www/cmh/skins/default/icons
But you have to remember the following every time you create a new version. For each icon in your file list:
Then and only then can you create a new version.
I also install the version and verify that all the files are installed in the right place.[/quote]
Thank you, Richard. I had thought I had done that, but I obviously messed something up so I backed it out. I will try again in the next release because it’s obviously better to have all the files on the Vera.
From here I see nest.com is doing maintenance on their site, and at about 12:25PM PST the plugin here stopped getting status. The maintenance window is supposed to end in about an hour. Assuming all is the same when it’s back up, the plugin ought to reconnect and update properly with no intervention. Please report if you see otherwise, thanks!
About the maintenance outage, I saw that support.nest.com reported the outage over but my Vera was still getting connection refused. I think there was a lag in when the Vera’s cached DNS entry for home.nest.com was cleared. So I ran an nslookup on home.nest.com from the Vera itself, and (maybe coincidentally) on the next poll attempt, the plugin succeeded in logging in again and retrieving status. Just an FYI.
I recently encountered a situation where my Heating Set Point was reduced lower than I would like (Cleaning People?). This was a problem as the house got pretty cold (63[sup]o[/sup]F).
I thought it was a good idea to setup a notification for this scenario, but when I checked the notifications tab there is no option for ‘Thermostat HEAT Set Point Goes Below’.
Is this an option (future release), or should I be trying to accomplish what I want in a different way?
I recently encountered a situation where my Heating Set Point was reduced lower than I would like (Cleaning People?). This was a problem as the house got pretty cold (63[sup]o[/sup]F).
I thought it was a good idea to setup a notification for this scenario, but when I checked the notifications tab there is no option for ‘Thermostat HEAT Set Point Goes Below’.
Is this an option (future release), or should I be trying to accomplish what I want in a different way?
Thanks for your assistance.[/quote]
The set of triggers for heat and cool setpoints only had in mind energy usage, like if someone set the heat too high or the A/C too low. But it does make sense to want to trigger on the setpoints being moved in the other direction too far out of comfort range, like someone setting the heat too low or the A/C too high. So I’ve added those triggers to the end of the list of triggers in the JSON file (attached). You can either upload the file, overwriting the current one, and check “restart Luup” to have it take effect, or you can wait until the next plugin release.
Let me know if you decide to upload this file and if it addresses the concern.
Thanks,
watou
Edit: P.S. The Nest has the ability to keep kids, workers, etc., from changing the thermostat settings with the use of a PIN code. I’ve never used it, and I don’t know how it interacts with the plugin, but I believe that is the intended feature for keeping unwanted fingers from changing the thermostat settings. Please let me know if anyone experiments with this feature and how the plugin deals with it. Thanks!
Please let me know if anyone experiments with this feature and how the plugin deals with it.
I was able to set the PIN remotely through the Nest app. I don’t see any negative results with the plugin. Even with the PIN set I can still fully control the Nest through Vera, and the notifications continue to function. This is also true of the native Nest app.
The only negative was that I forgot to give the wife the PIN. She was locked out of the controls. Doh!
[quote=“knewmania, post:154, topic:171456”]…
The only negative was that I forgot to give the wife the PIN. She was locked out of the controls. Doh![/quote]
Oops! Thanks for checking that. That’s what I suspected but of course I was just being lazy.
How difficult would it be to use D_HVAC_ZoneThermostat1 instead of D_NestThermostat1? The custom Nest thermostat doesn’t work with iVera. It just shows an unsupported device.
I tried hacking the code to use it. It sort of works, I can see the current setpoints, and I can control the fan. (From the web control panel or iVera). It doesn’t show the current heat/cool mode (thinks it’s “off”), or the current fan mode.
The custom thermostat also does not work very well with UI4 on a Vera 1. (I fully expected issues when I hacked out the version check ). I was more surprised at how close it comes to working!
[quote=“djrobx, post:156, topic:171456”]Very nice, great work!
How difficult would it be to use D_HVAC_ZoneThermostat1 instead of D_NestThermostat1? The custom Nest thermostat doesn’t work with iVera. It just shows an unsupported device.
I tried hacking the code to use it. It sort of works, I can see the current setpoints, and I can control the fan. (From the web control panel or iVera). It doesn’t show the current heat/cool mode (thinks it’s “off”), or the current fan mode.
The custom thermostat also does not work very well with UI4 on a Vera 1. (I fully expected issues when I hacked out the version check ). I was more surprised at how close it comes to working![/quote]
I haven’t used the iVera app and I’m not sure what it expects for each device. I know there is another smartphone app that depends on device type names, but its author is planning to instead interrogate service types to eliminate the need to maintain a mapping of device types to the service type(s) they implement. And there are yet other smartphone apps that properly interrogate implemented services and don’t have this issue. Have you reported the problem to the iVera app maker to see if they plan on removing this limitation? That change ought to make their app compatible with other devices as well. I use the AutHomation app for Android by garrettwp and it works great, and the HomeWave app for iOS is also pretty slick.
And about UI4, I don’t have it to test with, so I explicitly limited the plugin to only work with the version I have or later. I suppose someone could carefully backport it to support both UI4 and UI5, but I wouldn’t be the one to do that since I don’t have UI4 to test with, or any experience with it. The code is located at [url=https://github.com/watou/vera-nest-thermostat]https://github.com/watou/vera-nest-thermostat[/url].
Thanks - Yep, I’m essentially looking at backporting your code. It seems pretty do-able since it mostly already works. I was just curious if you knew of a specific reason that would prevent it from working with the built-in D_HVAC_ThermostatZone1. Using that would kill 2 birds with 1 stone - it’ll make it work with iVera, and it already has a UI that works in UI4. I’ll see if I can make it work.
iVera is essentially dead. The software developer hasn’t updated it in a very long time. But, it’s by far the best iOS app for my purposes. The others I’ve tried (SQRemote and HomeWave) start you out with a blank screen and expect you to design a user interface. I probably have 40 devices attached to my Vera 1 - designing a UI around them would be an extremely painful process, and it creates more work when I add new stuff.
Right; it doesn’t seem likely the iVera app will be changed. As for the painfulness on designing your own UI, I was actually surprised how quickly I was able to set something up in HomeWave, compared to SQRemote. The difference being that I always find myself spending time attempting to get everything (semi-)neatly aligned in SQRemote. With the (fairly flexible) grid in HomeWave, things are a lot faster and look nice. Obviously, you still have to configure each device to your liking.
Well, it needs to specify its own .json file, since there is no truly universal (and correct) thermostat definition. I think it’s better to ensure the device definition accurately reflects its real capabilities, instead of trying to force-fit it into a generic model that is kinda/sorta correct. IMHO.
Thanks for checking that. That’s what I suspected but of course I was just being lazy.
). I was more surprised at how close it comes to working!
