Only the connection for the configuration of the sensor runs over an open hotspot of the sensor. This hotspot is only opened by the sensor if no connection to a WLAN is possible.
After configuration, the sensor connects to the WLAN via WPA2. During normal operation, all connections are therefore made via an encrypted Wi-Fi connection.
Normally, no ports need to be opened. The notes only refer to specific routers. For example, the Fritzbox blocks access to NTP time-servers for devices connected to the guest Wi-Fi. But this must be possible for our sensor, so that we can check the certificates of the HTTPS connections in case of updates.
Basically, the connections are always made from the sensor to the internet, like any computer in the (home) network. Where necessary, we use HTTPS. Data is sent every 2 1/2 minutes, the time-servers are queried once an hour, once a day we check for firmware updates. We have tried everything to exclude possible access by hackers. But even we cannot give a 100% guarantee. So far, we don’t know of any case that someone has managed to gain access to a foreign WLAN via our sensor.
Unfortunately, there is no hint on the “we build a sensor” page that when you initially configure the sensor, your wifi connection is unencrypted. So, if you enter your valuable wifi password, it’s compromised in the moment you click the “save” button. I don’t see why initial configuration is not done by serial console. But someone would have to sniff your wifi nearby. How likely is it? NSA probably is doing this on a regular base from space, but…
Second thing is that your valuable password is stored on a device where you can assume software quality in relation to security is in a sense lower than on desktop systems. This is a problem in general with IoT devices, but also with cheap DSL routers, not-supported-anymore smartphones, wifi printers…
Th dangerous thing is to compromise the sensors over the air and then use them to open connections from behind the firewall. Everything bad could happen then.
The one who wants it paranoic safe
has to use a dedicated wifi + password only for the sensors (e.g. the “guest wifi” on Fritz!Boxes).
has to implement a filter rule to restrict all clients communication in this network only to the few domains the data should been sent to (can be digged from firmware sourcecode on github). Implementing a filter rule for a specific device only can be circumvented by MAC address spoofing, so may be useless.
has to block direct connections to IP addresses. Always DNS has to be used. If not, domain restriction is useless.
So, if something goes wrong with the sensor, it can cause no harm.
The “way in the middle” can be to simply put your sensor in the guest wifi. This will at least protect your computers in the main network and restrict communication to the allowed services.