SageGlass App - no remote access

[NSS]

We've recently downloaded the SageGlass App, which allows us to override any or all of the 4 zones of our installation, but only when we're at home. Now I confess that I'm not the most tech savvy of people (understatement), but I find it difficult to comprehend why it doesn't allow us to control the SageGlass from anywhere that we have internet access.

 

The control panel is connected directly to our wireless hub (hard-wired Ethernet cable), much the same as our CCTV, alarm system, SolarEdge, etc, and whilst I can view the status of the glass remotely, I cannot change it. SG tell me this is correct, but have not offered an explanation as to why, so I wondered whether any of you boffins can suggest a reason (or indeed a work-around)?

 

NB. SG say they are looking to add remote access via the app when the next generation controller is launched but no indication as yet as to whether it will be possible to upgrade current controllers.

Edited October 8, 2019 by NSS

[Mr Punter]

The epitome of a first world problem...

[NSS]

21 minutes ago, Mr Punter said:

The epitome of a first world problem...

Indeed, nice problem to have I guess, but it just seem odd that it will connect via Wi-Fi but not via the internet. In practical terms, are we losing anything? Potentially yes. For example, we have no blinds or curtains at the SG windows but tinting them does provide a degree of obscurity when viewing from outside that is a security benefit. On a cloudy day, we could still tint the glass (from afar) if we wanted to, or on a cold but sunny winter's day we could clear the glass to allow some extra solar gain, even if we were away for the whole day (or longer).

[Ed Davies]

To be able to access a device on your own LAN from outside on the Internet requires a couple of things:

 

1) Your router needs to be set up to allow packets addressed to the device to pass through from the Internet. This is doable but router specific and a right PITA.

 

2) Your app needs to know the global address of your router or device.

 

Both of these are tricky. Normally routers are set up to only allow in packets from the Internet which are replies to recent outgoing packets or are specially configured both for security reasons and for address-space reasons. In an act of bone-headed idiocy [¹] the original internet protocol (IPv4) was designed with only 32-bit addresses allowing roughly 4 billion devices to be addressed. Since most people use many more than one device needing addressing and there are quite a few people on the planet we've basically run out of addresses. A typical domestic DSL line only gets one IPv4 address to be shared by all the devices in the home using NAT. So your SageGlass device won't have its own globally routeable IPv4 address.

 

As well as the addressing problem there's also security. Given the dire state of security of most computers and related devices it's best if most of the world's hackers don't have access unless it's specifically required.

 

There are two possible solutions. One is the current version of the internet protocol (IPv6) which allows many more devices to be addressed (many billions of billions of billions, literally). Unfortunately, as a matter of general tardiness and bloody mindedness the computer industry has been very slow to take up the protocol. The standards were mostly stabilised in the late 1990s but it's still not in common use 20 years later, which is a bit pathetic really.

 

What most IoT devices do is call back to a central server somewhere which the app can also call in to to establish communication. Presumably this is the approach SG will use for their next version. It usually works OK but it has some critical flaws:

 

1) You're dependent on your internet connection working to do simple things, often even if you're at home on the same LAN as the device being controlled.

 

2) You're dependent on them continuing to run the server. Possibly OK if you have some sort of subscription to motivate them but very dubious if they're just promising to do so indefinitely out of the proceeds of the original sale.

 

3) There may be serious privacy concerns depending on the function being controlled, the software quality and ethics of the company concerned and so on.

 

[¹] Arguably based on racist assumptions, or maybe just a lack of confidence in the likely spread of internet usage.

[Ed Davies]

4 hours ago, NSS said:

… and whilst I can view the status of the glass remotely, I cannot change it.

 

Just re-read your post and noticed this bit. So it's not a matter of not being able to talk to your controller remotely, it's a matter of being able to access it but not command it. Speculating wildly, perhaps SG have realised that their protocol to whatever server is used to find the controller from the app and get the status is secure enough for those purposes (for privacy) but not secure enough to safely allow remote control. If so, 1 point to them for thinking it through sensibly.

[NSS]

46 minutes ago, Ed Davies said:

 

Just re-read your post and noticed this bit. So it's not a matter of not being able to talk to your controller remotely, it's a matter of being able to access it but not command it. Speculating wildly, perhaps SG have realised that their protocol to whatever server is used to find the controller from the app and get the status is secure enough for those purposes (for privacy) but not secure enough to safely allow remote control. If so, 1 point to them for thinking it through sensibly.

Odd thing is, if I (remotely) change a setting, for example put a zone into tint, the app view updates as if it has accepted the change, but doesn't action it. Tonight, when logged on to the Wi-Fi at our local pub, i did this. On returning home the zone was not tinted and upon opening the app it then updated the status to the actual (ie untinted) state. Whereas, if I open the app when I have no internet signal, the app doesn't allow me to log in, never mind change the status.

[NSS]

3 hours ago, Ed Davies said:

To be able to access a device on your own LAN from outside on the Internet requires a couple of things:

 

1) Your router needs to be set up to allow packets addressed to the device to pass through from the Internet. This is doable but router specific and a right PITA.

 

2) Your app needs to know the global address of your router or device.

 

Both of these are tricky. Normally routers are set up to only allow in packets from the Internet which are replies to recent outgoing packets or are specially configured both for security reasons and for address-space reasons. In an act of bone-headed idiocy [¹] the original internet protocol (IPv4) was designed with only 32-bit addresses allowing roughly 4 billion devices to be addressed. Since most people use many more than one device needing addressing and there are quite a few people on the planet we've basically run out of addresses. A typical domestic DSL line only gets one IPv4 address to be shared by all the devices in the home using NAT. So your SageGlass device won't have its own globally routeable IPv4 address.

 

As well as the addressing problem there's also security. Given the dire state of security of most computers and related devices it's best if most of the world's hackers don't have access unless it's specifically required.

 

There are two possible solutions. One is the current version of the internet protocol (IPv6) which allows many more devices to be addressed (many billions of billions of billions, literally). Unfortunately, as a matter of general tardiness and bloody mindedness the computer industry has been very slow to take up the protocol. The standards were mostly stabilised in the late 1990s but it's still not in common use 20 years later, which is a bit pathetic really.

 

What most IoT devices do is call back to a central server somewhere which the app can also call in to to establish communication. Presumably this is the approach SG will use for their next version. It usually works OK but it has some critical flaws:

 

1) You're dependent on your internet connection working to do simple things, often even if you're at home on the same LAN as the device being controlled.

 

2) You're dependent on them continuing to run the server. Possibly OK if you have some sort of subscription to motivate them but very dubious if they're just promising to do so indefinitely out of the proceeds of the original sale.

 

3) There may be serious privacy concerns depending on the function being controlled, the software quality and ethics of the company concerned and so on.

 

[¹] Arguably based on racist assumptions, or maybe just a lack of confidence in the likely spread of internet usage.

Many thanks @Ed Davies, I'd like to say I understood all of that but I'd be lying. Not sure where this fits into the puzzle but SG assigned a fixed IP address to the controller to enable the app to access it (albeit only when we're at home). 

[Ed Davies]

9 hours ago, NSS said:

…but SG assigned a fixed IP address to the controller to enable the app to access it (albeit only when we're at home). 

 

That'll likely not be a globally routeable address but rather one in one of the local address blocks [¹]: 10.nn.nn.nn or, more likely, 192.168.nn.nn, probably 192.168.0.nn if you've got default router settings. Almost everybody's home LANs (Wi-Fi and wired) use addresses in these blocks; there are many millions of routers all with the address 192.168.0.1. There's no way to directly use that address to access the device from outside your LAN. If all the devices in people's home had unique globally routeable IPv4 addresses then we wouldn't be running out of IPv4 addresses now, it'd have happened a decade or more ago.

 

Instead such communication has to be either via a server (run by SG, presumably) which does have a globally routeable IP address or it could be sent to the globally routeable IP address of your router if that was configured to forward packets (with some particular destination port number) to your SG controller.

 

There are two complications with configuring your router to forward packets to your SG controller: firstly the way it's set up varies from router to router and holding user's hands to get it configured properly would be a support nightmare for SG. It's possible that their controller could talk to your router and get the configuration set up automatically (using UPnP [²]) but that's not always going to work. E.g., I've got UPnP disabled on my router - can't remember if that was the default or I turned it off myself but whatever…

 

The second complication with using the router to forward packets to your controller is that the external IP address of your router could change. Some ISPs assign a static IP address to each user, others just assign one from a pool of numbers when a user connects so any time you turn your router off and on again you'll likely get a different IP address. Again, a support nightmare for SG if they tried to rely on that.

 

[¹] https://en.wikipedia.org/wiki/IP_address#Private_addresses

 

[²] https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal

[NSS]

Many thanks @Ed Davies, now I get it and, as you suggest, the fixed IP address does indeed sit in the 192.168 set. I guess I'll just have to wait and see what they come up with. Cheers ?