It's not too tricky anymore, new code requirements for new construction strongly recommend the smoke detectors to be linked so that they all go off at the same time (it's not a requirement... yet). So there are a tone of manufacturers out there that have interconnected alarms..
That said.,... they all suck.. honestly, the Nest Protect is probably the best one out there. I have 4 of them, and I really hated when Google bought Nest....
Will anyone fess up to working on an integration yet?
I think many, like myself, abandoned Nest a while ago, when Google shut down the Works With Nest program. They should have allowed for an overlap period to encourage migration instead of an exodus. 
That’s fair but it’s really to large of a platform for hubitat to ignore it.
I never implied it was being ignored by Hubitat... Just that the community devs might not be too excited to work on it if they no longer have Nest devices. I switched to Ecobee and am much happier with the comfort level of my home.
I'd love to get the video streams working. I've been poking around in the API documentation and think I've confused myself more than anything. Going to call a programmer buddy and see if he can take a look.
Really? It is in the UK has been for years
It is a LOCAL code requirement in many, many places in the US. So many, in fact, I wasn't aware that it wasn't a national code requirement...
Yeah, as @BorrisTheCat mentions, in the UK it's been a requirement since the early nineties at least for houses of more than two stories, IIRC. In my place they achieved this by cabling all the smoke detectors together, but they didn't bring a mains supply to any of them! 
Instead, they went with battery operated units, all of which were completely useless by the time we moved in. They were a big name brand, but when we got in touch they hadn't produced that model for years. Nobody else made a battery-powered, wired-interconnect detector and the only one that got close was the Protect with the wireless interconnect.
I suppose I could have pulled cable from the lighting circuit, but we'd just had all the ceilings and floors done. 
They're stupidly expensive (and had some issues in the early days) but they've always worked for me. And the little pathfinder light is way more useful than I'd expected, even if it's a half acknowledgement that Google likely know my family's sleeping patterns, when the house is occupied and whether the dog needed to go out in the night.
100% for me, one of the best and most unexpectedly useful features!
Plus (at least for me) the Nest Protects are very family friendly, the voice part makes them feel like they know what's going on. My other ones (First Alert Zwave) are not well loved.
I'm really bummed/PO'd that they didn't include the Protects. I'm dumping my Nest thermostat, but would like to keep using the Protects.
All new construction, and major renovations required hardwired smoke detectors. But they do not require (although most do these days) linked communication yet. Not sure why, it's a pretty basic function to implement. I Grew up in South Africa, all our smoke detectors have been linked for as long as I could remember.
I really do have a love hate relationship with Nest/Google. I did have one of the problematic ones, but Nest (pre google) replaced it for me. I have 4 currently, I should have far more, but I only replaced the existing ones in the house when I moved in.. To be honest, there is no reason they should be as expensive as they are, but I like the physical form factor as well.. the major brand ones just look ugly
So I've done the following:
What is the next step to have the API for my Nest Doorbell get into Hubitat as a variable?
Write an app in Hubitat. Once we have some examples to work with I'm sure there will be a lot of apps to pick from but it seems like all the devs are waiting to see what someone comes up with before taking the plunge.
Is there a generic app I can use as a starting point? I have no idea how HE would get a doorbell API ring notification. Is it a push message, is it polled?
I think that is the issue everyone is facing now. It's a lot easier to build from an example then start from scratch and dig through all the documentation. From what I saw in the documentation it looks like event subscription. Tell me when this changes and I'll leave you alone until I hear from you. A lot like the community Google home integration as far as I can tell.
I don't think HE can support the "push" event subscription model currently -- as it doesn't provide a way to receive POST requests (Maker API supports GET). As for the "pull" event subscription, it seems that Google has some Java libraries and code examples available -- I'm not sure how easily they could "plug and play" into a groovy app in HE...
Reference: Receiving messages using Pull | Cloud Pub/Sub Documentation
Hubitat’s Maker API would not be the correct solution for integrating with Google’s new Nest API. I would start with a Hubitat Groovy App, with OAUTH enabled, to handle all of the asynchronous updates from Google. The App would then create child devices for thermostats.
I think we're on the same page -- a groovy app in HE using the "pull" event subscription.
My reference to the Maker API was only in the context that -- AFAIK -- it is the only interface for the hub to receive HTTPS requests via a public IP with a valid certificate (the Hubitat Cloud), which would be required for Google's "push" event subscription.
Understood... however, what I am trying to explain is that your current understanding is not correct. Hubitat does support unsolicited push updates. No polling required.
Download the Hubitat app
