Google Home

On this i agree, it still an “one off situasjon”.
But i think it shouldn’t be to complicated,
As they have said it can cast everything from the device to your connected tv, with voice control, i will be surprised if they cant do it.
All the calculations are done in the “sky”, and not on the phone/device/etc, and content served through web, and they explain in the video that you can talk to any of your devices Phone/home/tablet/ etc, and show to whatever device you ask for.
So as long as one off them are nearby it should work, i guess…

I’ve also asked @DParker to rephrase his question several times.

They have said a couple of the videos that you cast your whole screen to a connected tv yes.
Shouldn’t be that more difficult than when i am casting now from my phone to the television.

But when it comes to an hdmi adapter, i dont know, but it could be as simple as “send it to my old phone”

Off course then you would have named your phone as " old phone" in your settings :slight_smile:

But casting screens arent difficult, or new even.
It has many names, on my laptop it is called “WIDI”
My phone “smart view”
My other phone and tablet “cast”
My other computer “media device service”
Etc, its almost a different name on every device i have.
But they all find and connect my " TV - LIVING ROOM" or “TV - BEDROOM” when i ask them to.
The tv’s just do what theyre told, and switch to whatever ill send them when i broadcast to them.

Base on the current assistant, the choices that was provided is an option that may be available to you as an option that you can click. I don’t know how it would work with a voice assistant but I would say it might work like a IVR type system.

As for having it cast to Chromecast not necessary, it really depends, but if you have something playing on TV, you don’t really want it to automatically override what you’re watching unless you tell it to.

This is a wake up call for ST when the next semiopen platform rolls around…

2 Likes

Or ST might drop support for both GH and Alexa if Samsung comes up with it’s own home assistant solution…

2 Likes

Definitely possible:

1 Like

Anyone know if Google Home is a DLNA compatible speaker? If it is we could use the one app out there to make it work as if it was a SmartThings supported speaker.

1 Like

A Z/IP and Thread Gateway from Google/Amazon would open the entire market up to a new distributed and open architecture. This would make your IOT/HA basically a commodotized hub not unlike a wifi hub you buy.

@ady624 can productize his rule engine into a daemon you run on your own compute to interact with the the devices those gateways make available via IP.

Game over.

1 Like

If it were that simple, it would’ve been done already. Z/IP has been available for almost 2 years and SmartThings, Wink, Iris and vera have all gone through major model releases in that time. None have adopted Z/IP.

I don’t know all the reasons, but I’m sure some of it is security. Z/IP is not a particularly secure protocol, and you would open up the possibility of a Mr. Robot type attack scenario.

The things we hate most about zwave, the physical need to handle the devices and the difficulty of switching to a new controller are exactly the things that tend to prevent somebody sitting in Chicago from maliciously taking over a home automation network in Atlanta.

I’m not saying we’ll never see a Z/IP DIY home automation system on the market, I’m just saying there are probably good reasons why we haven’t seen one yet.

2 Likes

While there are many more attacks and knowledge about attacks on IP stacks, there is also much more knowledge about defending the the same. Zwave and Zigbee are, in a way, security by obscurity in scenario you describe. Obscurity is not security.

I would also add that regardless of direct IP mappings - which I agree we need to secure - today’s scenario around the security of HA systems has the same concerns. Today the entire Zwave and Zigbee HA’s we have here, at ST and most other modern HA solutions, have an IP endpoint or many as it may be - both the ST hub and the cloud infrastructure of the same are subject to attack. If one can attack my IOT devices via an Z/IP gateway - they can do so via my ST Hub or via the ST cloud as well because they have IP stacks.

I don’t think you or I can really say that one or the other is more or less secure at this point. I for one, would rather control my destiny - I have much more faith in my ability to defend my IP devices than I give ST credit for being able to do. That being said, I realize that is not for everyone. I will just add that their IP based systems are still subject to attack - that includes their computers, their phones and yes their ST hub, the ST Cloud and therefore their Z based HA devices and their entire HA deployments.

One thing to consider is that it is not necessarily in their interests to do so, because it commodotizes the market and they are out of a job. The dynamics we see around Google Home and Alexa may have a future in one or both of them, or a third party like netgear, making a Z/IP gateway and changing the entire market.

Amazon and Google seem to have taken a completely different approach to HA thus far, and I find it interesting that they chose a technology that for now won’t be as easy to comodotize and really makes the interaction with some of the HA devices we have today just in need of a very simple gateway. Yes a logic engine is missing as well, which is why I mentioned solutions such as Ady’s.

At least I hope so…

The requirement to have physical access to a device before being able to change it to a different network controller is, I think, by definition significantly more secure than anything that can be done with software only.

I would agree, but I am not sure I understand the differentiated value of the security between the two scenarios. It would prevent one from removing a device from your Z network and putting on one they control, yes - but that would remain true if it were on a Z/IP gateway or connected to a ST HA hub.

Edit: I think I see what you are getting at - you can directly access individual devices via IP, essentially removing the existing “CONTROLLER” concept in HA Z networks. Therefore you can commandeer the device directly.

True. However, again, if you can do that you can also commandeer the entire ST hub or the ST via the cloud as I eluded. It comes down to how they are secured and who you can trust. A Z/IP scenario would not be inherently less secure than the existing HA models - ST, Wink, Homeseer, etc - My 2 cents on that. You don’t need physical access to the ST hub or the ST Cloud - they have IP stacks that can be attacked of course. So unless I am misunderstanding I am not sure how physical access is a differentiator and provides security in one that is absent in the other.

For all we know, I can log into a machine in the ST cloud via SSH using admin/admin and control everyone’s ST deployments end to end. And the chances of something like that being real are very very high, it’'s just undiscovered/unknown.

You’re right that once there’s any cloud piece, you’ve opened a vulnerability.

But Z wave itself doesn’t require a cloud. An Aeon zstick running Z/IP would be much more vulnerable than its current architecture.

The SmartThings architecture is a whole separate issue. :wink:

2 Likes

Absolutely correct. But, unless you want or are willing to accept a closed loop system - you will require that Zwave network to be connected to your IP network to interact with other devices on prem. Then you may extend that on prem IP network to interact with the cloud to get alerts on your phone or integration with other services such as Alexa…

The minute you do that, you’re back to the Z/IP scenario. The IP stack can then be attacked without physical access.

So only very limited Z network deployments (air gap) would enjoy a elevated level of security due to a physical access requirement.

The IP stack can be attacked, but many Z wave based architectures only use the Internet for notifications. There’s no device control. That’s all local. So you don’t need an air gap. If you don’t accept control statements from the cloud, somebody hacking the cloud doesn’t change what your local devices do. It might change who gets notified about events, but it’s not a device level incursion.

Echo, of course, represents its own point of vulnerability. At present it can’t add or remove devices from the network, or alter existing rule sets, but it can request that devices be turned on or off. And that could be spoofed. So again, that’s a whole separate issue, but one that is also likely to occur with Google home.

I believe there is a difference between what these systems make available, and what they are capable of. If the system, if completely controlled by an attacker, simply does not have the ability to issue commands to devices or shut down certain actions, or notifications, etc… then you are right. But I suspect if one took over say a Aeon Zwave ZStick, they could interfere with it’s operations in significant ways or even manipulate the system at will - even if it’s only intended interaction with systems via IP is via notifications.

Via the cloud yes. This also assumes the attacker would only have available to them published APIs and access methods. Which normally is not the case, and certainly not the goal of the attackers. The attackers will seek to subvert the systems and bypass not only their attempts to thwart unauthorized accesss but also any limitations on what they can do or execute via the various interfaces made available - ultimately they would go after the kernel and be able to do anything. Only limited by what that individual system is capable of. So yes, if you attacked the cloud portion you are limited by what that cloud system can do (note not limited to the API or other interfaces of said cloud system) - but if you go after and successfully attack a ZStick or ST Hub - you potentially have a much broader range of control available to you.

Can one shut down a Aeon Zstick remotely even if that isn’t a intended function of the device? It’s likely. Crashing the IP stack with a overflow may allow an attacker to issue some arbitrary command allowing them to further induce a complete shut down of the the device and therefore the entire zwave network for example. Additionally, hypothetically speaking the a Zstick device may only expose functions via an APi or what not relative to notifications - HOWEVER, that does not mean that gaining the ability to run arbitrary commands or code on the system via some attack would not allow a much broader range of manipulations than those that are available via the published APIs and other itnterfaces.

The same scenario is true for one that attacks the ST hub. No echo needed. If someone were to successfully attack an ST hub, they could likely issue arbitrary commands way beyond the scope of what ST has intended to make available.

And while these attacks are very difficult, the same is true for a Z/IP gateway - hence I don’t see the differentiation. Only that in one scenario you trust or rely on a third party’s architecture and security, which, I agree is normally sufficient and what most folks want.

Not really. without Z/IP, Z wave commands are just bouncing around the Z wave network. They’re not accessible to anything outside of it.

Sending notifications isn’t a Z wave command at all. It just means you’ve added something to the hub processor itself to recognize that certain Zwave events have happened and then do the notifications. But it doesn’t give you any control access to the command structure of the Z wave controller.

It’s pretty much the equivalent of having an acoustic sensor recognize when A smoke sensor sounds an alarm. That capability doesn’t in any way give the acoustic sensor device a means of interfering with the smoke alarm.

As for jamming the Aeon zstick, no, it just doesn’t work that way. The Internet connections are all handled by the laptop or other device that the zstick is plugged into. The Z wave is handled in the Z wave controller inside the stick. Flooding the IP stack in the notification module on the laptop won’t have any effect at all on the zstick’s ability to run the local Z wave network. It’s not even aware of the notification activity to begin with.

Depending on the exact configuration, you might be able to cut the power to the laptop and so deactivate zstick altogether, but the interesting thing about zwave is that the local devices can continue to talk to each other even if the controller is down. So motion sensors can still trigger a siren and lights even if the laptop died.

Anyway, I’m tired, so I’ll leave it at that. Just to stay on topic, I will again emphasize that as soon as you allow for voice control that can be spoofed, you’ve opened a major area of security concerns.

Just will point out this is a air gap and easily recognized as a strictly one way communication system. This is very different than the zstick or ST hub scenario.

A Zstick may require you compromise the laptop or other system via it’ s IP interface, then further compromise the Zstick via USB to be able to influence the z network or devices somehow, but that is clearly not a strict one way communication based system. Each system in the chain is bidirectionally communicative.

Same would be true for the ST Hub. If you were to hack the kernel on a ST hub, I would imagine the world would be your oyster.

You nailed it…including the fact that contrary to the multiple childishly belligerent claims to the contrary, none of the videos cited contain any demos of any such functionality.

1 Like

Then none of your claims were valid, and you have an awful lot of crow to eat.