The possible values are named differently in the 2.2. binding. Most values are in caps now. The documentation list the possible values between round brackets. So this will probably work:
I was missing them too and added them a few days ago with PR #3024 which should be part of the 2.3.0-SNAPSHOT builds. Since the official documentation did not yet get updated you can check the source code documentation instead. Probably youâll need to delete and re-add the respective Things before youâll be able to see and use these new channels.
That solved everything, the new channels for Nest Protect Date/Time seem to be working also with the latest SNAPSHOT (I did have to delete and re-add the Things, but it was easy).
Rather than having a separate Fahrenheit binding, would you consider simply adding another channel to the Nest Thermostat Thing for the Fahrenheit value? I believe we had the choice of both F and C with the v1 binding so it is disappointing to have to maintain a separate custom install now. Adding a channel has no downside that I can see, but perhaps I am missing something.
Regarding the Unit Converter, that would work but we would get different temperature values via the conversion than the thermostat reports via the API. I would prefer to have the values that Nest reports.
The new QuantityType is almost there and definitely the cleanest way to implement this. The Weather Underground binding will also be using it once it is merged. So this will probably all make it into OH 2.3.
When the binding updates channel states it can choose what unit is used (see WU implementation). So we can let the binding update state using the Fahrenheit values (or Celsius values) received by the API depending on the temperature_scale property of the Thermostat.
I super curious how this would work. Yes, you can convert C->F and F->C however:
In Fahrenheit control mode, Nest can be changed in 1 deg F increments only (0.55 deg C)
In Celsius control mode, Nest can be changed in 0.5 deg C increments only (0.9 deg F)
I donât think you could simply take the input from a control in F, convert to C and send the command to the Nest. There would need to be built in logic to fix these differences. Iâm curious how Quantity type handles that.
âAlmost certainlyâ is the key word here. Why do we have to assume what the functionality will be? The binding will have to do conversions to make sure the value that is being sent is valid; I donât see how that is possibly cleaner when the API supports both F and C natively. I get that it is a good choice for something like the WU binding, but that is a read-only binding, and the fact that we need to both get and set temperatures makes a difference, in my opinion.
Sorry, perhaps I missed it but I donât see a link to a discussion specifically regarding using the QuantityType binding to convert C to F in the Nest binding. I only see links to the QuantityType PR and the WU example. I also searched open issues and PR on the oh2 addons repo.
Iâm happy to comment on a PR or issue on GitHub if this forum is not the appropriate venue for this discussion.
It isnât that this forum isnât a good place, but to reach the people who are actively working on this code you have to go to where they are working.
Sorry, again, that doesnât seem to be the right place. That appears to be the general discussion for the QuantityType binding and not the discussion about the specific point I raised regarding how the Nest binding will handle F and C values. Posting about the Nest binding on that PR seems off topicâŠ
It isnât off topic because if the Nest binding will need to use that service, then the logic you are concerned about (i.e. converting between the two based on limited and incompatible precision) would have to be implemented there, unless @wborn provided the wrong link or Iâm misunderstanding what he is proposing how this would be used to implement this.
Iâm dusting off my OH install after a distracting 7 months, and canât get the nest binding to work.
I started with a new Openhabian install, and moved my configurations over.
I requested new credentials for a nest app, and structures and everything appear in the things inbox.
However, I canât get my items and sitemaps to display. Iâve renamed no items in the nest app.
Yes, Iâve accepted the items. I can see all the channels underneath.
But what does âlinking items to the channelsâ actually involve?
Do I cut/paste something from a thing to my standard.items file? Why would my old entries not work?
Do I do something using paper UI? Should I be using a different tool?
When I do link an item with paper UI does it add an entry in standard.items? I see some weird entry in Visual Studio, which I am still unsure of where all these items are.
I know I am being somewhat obtuse with this, but this is really not very intuitive. I felt like I had a reasonable laymanâs handle on it when I stopped maintaining my environment, but I feel like I really do not know where to begin since returning.
No, and as far as I know, you cannot link an Item to a Channel on Items defined in .items files.
Do you have Simple Mode turned on under Configuration-> Server? If so, a new Item will be automatically created for each Channel on each Thing and the name of the Item will be the name of the Channel. These Items are not stored in your .items files.
and winner winner chicken dinner - previously, I was suffering since moving from OH1 to OH2.
Top work guys!
Now only dumb q
I can control temperatures, etc via the binding / switches etc just fine, but could someone tell me⊠how do I fully disable one Nestâs built in control so permanently override it with my own OH code?
I am coding separate, individually zoned rooms - so literally want to use one of my Nests as an on/off switch (*while the other gets left to do its own thing)
I donât think this can be done. You can empty out the schedule on the Nest and you certainly should turn off the learning. But as far as I know, it is impossible to turn the Nest into just a âdumbâ thermostat.
