Data traffic control of OH cloud connector, unnecessary data transmission, proper connector configuration

My current Setup:

openHABian 3.1.0 on RaspberryPi 3 Model B V1.2 1GB
openHAB Cloud Connector 3.1.0
Used Cloud-Service : https://myopenhab.org/
Android App 2.20.0

I want to access my remote flat where I placed an mobile WLAN hotspot. I am looking now for a proper configuration for the simple use case of just occasional starting the Android app and looking to the temperatures and the temperature group chart.

Unfortunately the traffic between Openhabian and Cloud is full time ongoing with high data rate and eating up the flat-rate volume limit of 100MByte of my mobile contract in just 3 days.

Nevertheless, it is a probably unwished load of the community cloud service, as the continuous data transfer is not needed/wished.

I have none of my items exposed in the cloud connector menu

I had to put the operation mode of the cloud connector to “Notifications & Remote Access”, as enabling only notifications is not showing any item on the smartphone

I logged the WLAN traffic between RPi and Hotspot and see 98% is TLS data between Cloud (172.104.246.157) and local RPi (192.168.19.100), roughly 3 packets per second, leading to 800 kB/hour , 19.2 MB/day or 600 MByte/month.

I found Bandwidth limits and playing nice with myopenHAB.org openHAB Cloud where Rich pointed out the 3 transfer types, but I do not understand why the transfer is continuous, if no smartphone is connected to the cloud service.

My cloudconnector config is default/empty also.

Can anyone explain this behavior (or my mistake) and guide me to a documentation of cloud connector details, e.g. there must be configs somewhere to set the stay-alive ping time etc., but I do not find them here or on github.

Thanks
Tim

The data is from openHAB to the cloud connector.

What you could do is run your own instance of the cloud connector locally so all that data is on the internal network and then connect to it with your smart phone through your router.

There is currently only 2 transfer types, the 3rd was for IFTTT and it was disabled and AFAIK it was not turned back on again. It was (not currently) because a website called If This Then That needed the items changing all the time so that it could work.

There will always be data out going as a packet needs to keep the firewall open, this is how it works without you needing to open a port as the software inside your network sends a packet out and this allows it to work with no open ports.

There is probably no config, it is probably hard coded and I do not know the details on how often it will send a packet out to keep alive the connection through the firewall. Someone may reply here but if you don’t get one in a few weeks, try on github as 3 packets every second seems high to me, but I really have no idea on this. Doing a search on github may turn up some other issue tickets which mention this.

Just to confirm, IFTTT support was not turned back on. However, the option to expose items still shows up in MainUI since people who use their own cloud servers might need it.

Could you get what you need by having the remote system send you periodic updates via Telegram or MQTT?

Thanks for this tip, in deed I tried on that solution also in parallel, but it seems my mobile network provider is not allowing incoming traffic to the cellular NAD. Anyway, keeping a router port open would not be my favorite solution.

Thanks for the tips, I tried to follow github, I found some hardcoded ping times of 30s in a used socket.io library, but I am not sure about those code pieces. Moreover as I see now exactly 25s ping/stay alive time, see below.

Finally it seems to work properly now! After doing config changes in persistence and re-installing the cloud connector, I now see a proper behavior. Unfortunately I can not reproduce the high data load by applying my old config data and trying for last days. I just have the old logs, but as TLS encrypted, we will not know what was inside the data.

Now I see an expected behavior of a stay alive ping from 25,0 seconds from OpenHAB cloud connector to Cloud and acknowledge, 266 bytes in total, stable in size and time. This leads to 640 Bytes/min means 1 MByte per day, 30 MByte adder to my monthly mobile volume. That’s fair/acceptable.

Reading out the 8 Temps and history chart (via internet smartphone usage) leads to a Raspberry IP traffic of approx. 3MByte per minute of intensive usage time. I added the wireshark charts for those who are interested. They show the quiet ping phase and in the middle a 2 minute usage from my smartphone in the internet. I take the issue as solved and hope it stays to that :wink: Thanks for the support here, Tim.

That’s more what I would have guessed was all that is needed to ensure if your IP changes at your home or the router reboots, that the cloud connection updates and the firewall opens to let the traffic through.
You really should keep a close eye on it because 3 packets a second when your not connected could be an indication someone else is that does not have permission. Of course it may be a bug in the code that causes a repetitive fetch of states, it may have been Google or Alexa talking. Lets not jump straight to the worse case right away, but keep it in mind to watch your logs and traffic.

If it happens again, login to the cloud website and you can remove permission from the apps and the 3rd party Google and Alexa connections. If you remove the permission and the data stops the moment you do, then you know they were the cause.

If you may have leaked your secret codes or cloud login details, then these can be changed and regenerated and may be a good thing to do as a precaution, regenerate the secret file contents (search forum and docs for how). Never type them into a website, email or forum. There was someone posting on this forum trying to trick people into entering their login details into their external website.

Lastly if it does happen again, look at enabling the TRACE logs on the cloud connector, it may just tell you what is happening or provide a clue.

1 Like