443:8123 is any TCP traffic regardless of protocol (http, https, ftp, etc.) so my question is…
If nest is using https://xxx.duckdns.org then the router is forwarding that SSL connection to https://my_local_ip:8123. Are you able to access your system locally via https:x.x.x.x:8123?
The battery is fine. It is never below 3.9V.
What seems to vary, from time to time, is the ping, which should be around 800-900msec and, sometimes I get spikes of more than 1000msec, which might cause some issues.
If the battery is fine and wi-fi is fine then it must be either your internet or a defective thermostat.
Was scratching my head real hard. Was about to start looking at the entire Docker network setup on the HA server (cries in IP table rules) and then decided Let’s restart the router!
…
It worked lol
I forgot the first rule of troubleshooting: restart everything!
Thanks again for your help and suggestions @dbrunt @allenporter
Duh! Linksys!
If that was a new rule, it should prompt you for a restart (or handle it automatically under the hood)…
Sometimes we overlook the simple things… I’m glad it was a simple fix!!
If you’re in Europe you have T1 and T2, that’s it. We don’t have a Common wire in our setup, as we use 240v with that square bridge (HeatLink is its name) doing the boiler/furnace job, and communicating wirelessly with the thermostat. Now you’ve got me thinking… Perhaps the issue could be the HeatLink! You can power the Nest using any Micro-USB cable and any 5V 2A phone charger. Do that for a while and see if it resolves. It could be signal issues between the HeatLink and the thermostat (not necessarily WiFi). By moving it around closer to the heatlink, or closer to the router, you can play with it and see if it works better.
Please DO NOT give electrical advice without being 10000% sure. He will fry his thermostat if he inputs 24V into it because his thermostat is European, it’s totally different than the North American version. It uses two separate pieces, one is called a HeatLink it looks a bit like a Philips Hue bridge, this uses 240 volts mains voltage to control a boiler/furnace, it’s connected to the boiler’s control board and high voltage supply from the house circuit. It communicates wirelessly with the thermostat itself (the round piece with the screen), which can be connected to the heat link to receive 12v for powering on the smarts only. It can also be powered on by a USB charger and Micro-USB cable. It does NOT support high voltage from the mains or 24V and will burn out. European Nest thermostats are just controllers (and contain the brains), but unlike the North American model the stuff that controls the furnace/boiler is the HeatLink. North American thermostats use 24v low voltage wiring I believe, hence your incorrect advice.
1 Like
My humble apologies. (post 1105 edited)
Thank you, I acknowledge you had good intentions.
I figured there was a regional difference… 
For some reason I had a day of solid connection to the app. No OFFLINE moments for an entire day.
I removed the thermostat from the backplate, checked the hardware connection was correct and reconnect to the backplate.
I will see if that fixed my problem.
If not I will follow the other suggestion from @anon78847916 of connecting the thermostat head to a micro-USB cable, I have also a stand for it.
Yes, there has been “progress” in terms of the number of subsystems that can be independently reloaded, but I believe this is mostly cosmetic (i.e., nothing substantial needed to be changed internally for those subsystems). I could never find an explanation of their design philosophy, and whether there is currently a fundamental reason why other types of entities (e.g., lights, boolean_sensors, etc.) don’t allow for this.
I have my suspicions, and I don’t like it. Basically, there is a (hopeless) attempt to analyze device logic and dependencies without support from the underlying templating language. HA templates are Turing-complete; with enough effort, one can create arbitrary computations. There is no way to “analyze” dependencies (e.g., print “all automations that depend on a particular trigger”). If they want this functionality, it should be supported by the language.
This is the goal of templating languages like Liquid (https://github.com/Shopify/liquid)–to limit the class of computations that can be done. In the case of Liquid, this is to avoid execution of insecure code.
That might be true, depending on what you mean by “print” and “a particular trigger”…
Is the info on the device/entity info screen what you are referring to?
I see this as another step in the right direction!
If this info is available in the core, there should be a way to extract it into a comprehensive report for display or hard copy…
As i mentioned before, If you want a serious answer i’d suggest a separate thread on these architecture topics, but i’ll bite here anyway: My impression is that this is supported by integrations higher up on the Quality Scale which was an effort started in 2018. This requires rewriting every integration to use ConfigEntries to support dynamic load/unload/cleanup. I literally see 2-3 PRs per week of people upgrading their integrations to use config entries to support dynamic load/unload. I’d suggest not thinking about it like a design philosophy disconnect, but something that is really difficult being implemented by volunteers.
1 Like
Hey guys,
i have added this integration, my 5 nest 3rd gen thermostats showed up
but i dont see the sensors ( the little white round things) that i have
does anyone have similar issues?
using badnest i had them all working great
Hi,
- For thermostats not showing up see https://www.home-assistant.io/integrations/nest/#troubleshooting issue with the nest api. The restart was needed for me to get nest api to show them.
- For sensors not showing up: See Supported Devices https://www.home-assistant.io/integrations/nest/#overview-supported-devices – sorry, I recommend leaving feedback for the nest api team
thank you bro, you got that to my brain
Additional Nest Temperature Sensors are not supported by the SDM API.
anyone know is that a google issue or the HA integration to be written more?
any to expect?
When Allen says that the SDM api doesn’t support it, he means the google api. Therefore there is nothing that can be done to the integration to add them.
Badnest uses a completely different mechanism, not supported by Google, so for the new mechanism we have to wait while google add capability.
Is there a way using your integration to get a photo snapshot of the last detected person? I want to create a picture card on my security dashboard that shows me a photo of the last detected person. There was a hack before you created your official integration, through NodeRed, that would let me do it. I stopped using that hack because I hate complexity, better to use one officially supported integration. I know it can be done, but not sure if you put the functionality into your own integration and if you did, how can I get the URL to provide for the picture entity card?
Edit: well, that was easy! I never noticed before but there’s a camera.snapshot service that can be used for any camera. I created an automation to call this service when the event “person_detected” is triggered, I set up the service to record to a jpg file inside the “/config/www/randomstringfolder/myfile.jpg”. Then, I created a picture glance card and used https://my.domain.com/local/randomstringfolder/myfile.jpg for the path and it’s working perfectly! Hopefully this can help someone else. It also works perfectly for the doorbell_chime event, I now get a notification with a picture of the person when the doorbell button is pressed. Perfect!
Glad you got this working! I also posted an update earlier in the thread of how to use this with the Home Assistant Companion App Notifications if you find that approach useful too.
@corvy I also wanted to give an update on the image latency problem for notifications. I just merged PR
https://github.com/home-assistant/core/pull/44638 which will use the image snapshot from the nest events API. I’d be curious to see if that solves your latency problems. It should make it into the 2021.02 release or earlier on the dev build.
1 Like
hi guys.I am trying to integrate the thermostat again but I have a doubt when it asks for the address https://<your_home_assistant_url>:/auth/external/callback
I use nabucasa. just copy the access link that of nabucasa by adding /auth/external/callback or should I add the port too? if so what port number?