Thought the same . . .just don;t want to set to 24 . . then OH crashes and I burn gas at an unprecedented rate
Should work well enough though - thanks.
Are you then letting Nest handle home / away?
Thought the same . . .just don;t want to set to 24 . . then OH crashes and I burn gas at an unprecedented rate
Should work well enough though - thanks.
Are you then letting Nest handle home / away?
I have some weird behavior going on with this binding. I was using the old binding which would give you a mode of âheatâ or âcoolâ etc.
This new binding seemingly does the same thing, but when I try to display the mode in the basic ui i get âheatingâ rather than âheatâ
REST shows that itâs âHEATâ and the log shows it as âHEATâ as well, but in the UI its âheatingâ
Text item=NestTStat_HVAC_Mode
any ideas why this might be?
You are using the wrong âthingâ. You are looking at the current status of
the HVAC (is is heating, cooling, off etc) and not the mode setting (HEAT,
COOL, ECO, etc).
i beg to differ:
String NestTStat_HVAC_Mode âMode [%s]â { channel=ânest:thermostat:2965c7dd:KeD484GZZTFkb3eBbV4EzVBPx9yKQrvJ:modeâ }
Hmm, guess I donât know then. The wiki here:
https://docs.openhab.org/addons/bindings/nest/readme.html
Shows âstateâ reporting âheatingâ, âcoolingâ, etc and mode reporting
"HEAT", âCOOLâ etc.
Iâve created a WIP PR for using the QuantityType for temperature values in the Nest Binding. Itâs mostly finished and uses Thermostat temperature scale setting to determine which values are used for reading/writing Nest API temperature values:
https://github.com/openhab/openhab2-addons/pull/3150
It seems to work well with both Celsius and Fahrenheit values after some testing. Now itâs just waiting for the upstream PR to get merged and review comments on my PR.
Great, thank you for letting me know! Iâll check this out.
Thanks Wouter. I created a PR on your fork to fix the error where we canât change the setpoint. Can you please merge, rebuild and post link to the new JAR here for everyone?
Thanks @Danny_Cohn!
Iâve uploaded a new org.openhab.binding.nest-2.2.0-fahrenheit.jar which will fix setting the Thermostat target temperature with Fahrenheit values.
It also includes the following OH 2.3.0 pull requests:
Hi all, Iâve been using the openhab 1.x version of the nest binding since using openhab 1 and after migrating to openhab 2. Iâm going to attempt to change to this version today now that fahrenheit is supported. I am currently running the 2.3.0-SNAPSHOT, Build #1206.
I just want to confirm the correct channel syntax for temperature. Do we need any special configuration like:
Number Thermostat_Temperature "Temperature [%.1f °F]" { channel="nest:thermostat:demo_account:living_thermostat:temperature_F" }
or just leave it as is and the binding will manage automatically?
Number Thermostat_Temperature "Temperature [%.1f °F]" { channel="nest:thermostat:demo_account:living_thermostat:temperature" }
*Many thanks to everyone who has ever worked on this binding.
Just refer to temperature, not _f. This version of the binding only talks in F, but does so without qualifying it as such via _f like the Nest API does
Iâve just switched over, updated my things and items. The cameras and protects are working fine, but the thermostat is not working. Throws the following error every few secondsâŠ
2018-02-08 16:36:57.382 [DEBUG] [g.nest.handler.NestThermostatHandler] - Updating thermostat DEVICEID_HERE
2018-02-08 16:36:57.416 [WARN ] [nternal.rest.NestStreamingRestClient] - An exception occurred while processing the inbound event
java.lang.NullPointerException: null
at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState(NestThermostatHandler.java:56) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.getChannelState(NestThermostatHandler.java:1) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.lambda$0(NestBaseHandler.java:135) ~[?:?]
at java.util.ArrayList.forEach(ArrayList.java:1257) ~[?:?]
at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080) ~[?:?]
at org.openhab.binding.nest.handler.NestBaseHandler.updateChannels(NestBaseHandler.java:135) ~[?:?]
at org.openhab.binding.nest.handler.NestThermostatHandler.onNewNestThermostatData(NestThermostatHandler.java:160) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:213) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.lambda$1(NestBridgeHandler.java:208) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.broadcastDevices(NestBridgeHandler.java:208) ~[?:?]
at org.openhab.binding.nest.handler.NestBridgeHandler.onNewTopLevelData(NestBridgeHandler.java:388) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.lambda$4(NestStreamingRestClient.java:206) ~[?:?]
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891) ~[?:?]
at org.openhab.binding.nest.internal.rest.NestStreamingRestClient.onEvent(NestStreamingRestClient.java:206) ~[?:?]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:687) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.notify(EventSource.java:681) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.onEvent(EventSource.java:668) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at org.glassfish.jersey.media.sse.EventSource$EventProcessor.run(EventSource.java:614) [180:org.glassfish.jersey.media.jersey-media-sse:2.22.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Itâs also marked as âwaiting to refreshâ:
The binding does appear to be getting all of the information from nest:
2018-02-08 16:44:33.440 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received âputâ event, data: {âpathâ:â/â,âdataâ:{âdevicesâ:{âthermostatsâ:{âDEVICEID_HEREâ:{âhumidityâ:25,âlocaleâ:âen-USâ,âtemperature_scaleâ:âFâ,âis_using_emergency_heatâ:false,âhas_fanâ:true,âsoftware_versionâ:â5.6.6-4â,âhas_leafâ:false,âwhere_idâ:âWHEREID_HEREâ,âdevice_idâ:âDEVICEID_HEREâ,ânameâ:âThermostatâ,âcan_heatâ:true,âcan_coolâ:true,âtarget_temperature_câ:20.5,âtarget_temperature_fâ:69,âtarget_temperature_high_câ:24.0,âtarget_temperature_high_fâ:75,âtarget_temperature_low_câ:20.0,âtarget_temperature_low_fâ:68,âambient_temperature_câ:20.0,âambient_temperature_fâ:68,âaway_temperature_high_câ:24.0,âaway_temperature_high_fâ:76,âaway_temperature_low_câ:12.5,âaway_temperature_low_fâ:55,âstructure_idâ:âSTRUCTUREID_HEREâ,âfan_timer_activeâ:true,âfan_timer_timeoutâ:â1970-01-01T00:00:00.000Zâ,âhvac_modeâ:âheatâ,âname_longâ:âThermostat Thermostatâ,âis_onlineâ:true,âlast_connectionâ:â2018-02-08T21:34:36.468Zâ,âhvac_stateâ:âheatingâ}},âsmoke_co_alarmsâ: âŠetc
It looks like the fan_timer_duration
property is missing which causes the exception @omatzyo . You can probably fix this by making sure the âThermostat read/write v6â permission is enabled in the Nest Developer console. This property was added in v6. See also the earlier discussion in this thread.
Iâll put in a PR in the future so null values no longer result in such exceptions.
You are absolutely correct. Iâm not sure how I missed that. Sorry. Updating to v6 fixed the error. Thank you!
I am seeing the same behavior.
openhab> smarthome:status Nest_hvac_mode
HEAT
2018-02-09 07:04:15.273 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received âputâ event, data: {âpathâ:â/â,âdataâ:{âdevicesâ:{âthermostatsâ:{ââ:{âhumidityâ:20,âlocaleâ:âen-USâ,âtemperature_scaleâ:âFâ,âis_using_emergency_heatâ:false,âhas_fanâ:true,âsoftware_versionâ:â5.6.6-4â,âhas_leafâ:false,âwhere_idâ:ââ,âdevice_idâ:ââ,ânameâ:âThermostatâ,âcan_heatâ:true,âcan_coolâ:true,âtarget_temperature_câ:19.0,âtarget_temperature_fâ:67,âtarget_temperature_high_câ:24.0,âtarget_temperature_high_fâ:75,âtarget_temperature_low_câ:20.0,âtarget_temperature_low_fâ:68,âambient_temperature_câ:19.0,âambient_temperature_fâ:67,âaway_temperature_high_câ:24.0,âaway_temperature_high_fâ:76,âaway_temperature_low_câ:12.5,âaway_temperature_low_fâ:55,âeco_temperature_high_câ:24.0,âeco_temperature_high_fâ:76,âeco_temperature_low_câ:12.5,âeco_temperature_low_fâ:55,âis_lockedâ:false,âlocked_temp_min_câ:20.0,âlocked_temp_min_fâ:68,âlocked_temp_max_câ:22.0,âlocked_temp_max_fâ:72,âsunlight_correction_activeâ:false,âsunlight_correction_enabledâ:true,âstructure_idâ:ââ,âfan_timer_activeâ:false,âfan_timer_timeoutâ:â1970-01-01T00:00:00.000Zâ,âfan_timer_durationâ:15,âprevious_hvac_modeâ:ââ,âhvac_modeâ:âheatâ,âtime_to_targetâ:â~0â,âtime_to_target_trainingâ:âreadyâ,âwhere_nameâ:âThermostatâ,âlabelâ:ââ,âname_longâ:âThermostat Thermostatâ,âis_onlineâ:true,âlast_connectionâ:â2018-02-09T12:00:03.411Zâ,âhvac_stateâ:âheatingâ}},âsmoke_co_alarmsâ:âŠetc
So, the binding does have the correct value:
"hvac_mode":"heat"
Here is my item:
String Nest_hvac_mode "HVAC Mode [%s]" (Nest_Therm_ground,changed_restored,Weather) { channel="nest:thermostat:my_home_account:ground_thermostat:mode" }
It also retains the âheatingâ value when the âhvac_stateâ updates to âoffâ.
Is there something that is processing this and changing to all caps? Perhaps its related to the strange behavior weâre noticing?
case CHANNEL_MODE:
return new StringType(thermostat.getMode().name());
case CHANNEL_PREVIOUS_MODE:
Mode previousMode = thermostat.getPreviousMode() != null ? thermostat.getPreviousMode()
: thermostat.getMode();
return new StringType(previousMode.name());
Iâm taking a stab here, but what if we remove the .name()?
I donât mean to hijack this thread with issues, but I seem to be running into quite a few. I want to say thank you again to everyone for the great work on this binding.
Has anyone had an issue coming up against the rate limit?
I have some rules that change the temperature in the house - similar to those mentioned above. It is not changed excessively⊠Maybe every hour or every two hours. With this version of the binding Iâm getting a lot of âblockedâ messages. Iâm not updating any other values. I have noticed (unless Iâm reading the log incorrectly) that the updating seems to happen every few seconds (or even every second). Iâm not sure how to control for this.
Here is a snippet from my debug log when I try to update the temp:
2018-02-10 10:06:03.923 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:06:03.924 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:06:10.334 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Putting data to: https://firebase-apiserver17-tah01-iad01.dapi.production.nest.com:9553/devices/thermostats/THERMOSTAT_ID
2018-02-10 10:06:10.491 [DEBUG] [nding.nest.handler.NestBridgeHandler] - PUT content: {"target_temperature_f":67.0}
2018-02-10 10:06:10.492 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Re-using access token from configuration: MY_TOKEN
2018-02-10 10:06:10.809 [DEBUG] [nding.nest.handler.NestBridgeHandler] - PUT response: {"error":"blocked","type":"https://developer.nest.com/documentation/cloud/error-messages#blocked","message":"blocked","instance":"0f42fcd1-dc4c-4f6b-8721-63523bb98e75"}
2018-02-10 10:06:10.810 [DEBUG] [nding.nest.handler.NestBridgeHandler] - Nest API error: ErrorData [error=blocked, type=https://developer.nest.com/documentation/cloud/error-messages#blocked, message=blocked, instance=0f42fcd1-dc4c-4f6b-8721-63523bb98e75]
2018-02-10 10:06:10.811 [WARN ] [nding.nest.handler.NestBridgeHandler] - Nest API error: blocked
2018-02-10 10:06:23.301 [DEBUG] [nternal.rest.NestStreamingRestClient] - Check: Receiving streaming events, millisSinceLastEvent=19378
2018-02-10 10:06:27.401 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":{...etc
2018-02-10 10:06:27.405 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:28.497 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:28.504 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:30.792 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:30.799 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:33.924 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:06:33.925 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:06:36.774 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:36.778 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
2018-02-10 10:06:44.439 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:06:44.458 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
...a bunch of things are handled
2018-02-10 10:06:53.303 [DEBUG] [nternal.rest.NestStreamingRestClient] - Check: Receiving streaming events, millisSinceLastEvent=8867
2018-02-10 10:07:03.926 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'keep-alive' event, data: null
2018-02-10 10:07:03.929 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received message to keep connection alive
2018-02-10 10:07:09.625 [DEBUG] [nternal.rest.NestStreamingRestClient] - Received 'put' event, data: {"path":"/","data":{"devices":{"thermostats":...etc
2018-02-10 10:07:09.630 [DEBUG] [nternal.rest.NestStreamingRestClient] - Data has changed (or initial data sent)
Hey @omatzyo I just submitted some PRs to change the code of the original binding pinkfish created. I havenât touched the naming/casing which is indeed a bit different from the OH1 binding. I think it is a little late in the game to change it now everybody is using it. The possible states are listed in the channel descriptions of the binding documentation.
The OH2 binding no longer polls the state every minute. Instead it now uses the Nest REST Streaming API so it is instantly notified of every change. I can imagine if you send a command each time an update occurs you can quickly run into the rate limit. The rate limits may also become an issue when you reuse the same OAuth token in multiple OH instances
Iâve already changed all my rules to use the all caps version of things and that is working fine. I just think itâs odd that the display string is different from the actual state of the item. Most things in openhab donât work like this. The state is âHEATâ but the displayed string is âheatingâ. I know there are exceptions. I though perhaps this was not by design. Regardless, it has been working in my rules
But I donât. Thatâs why Iâm confused. It only sends a command every hour or two⊠or longer. And this is my only instance in which Iâm running a nest binding. Is your log constantly updating this this, every second?