Not issue but feature request – Remote Control

[Vendrel]

Dear Developers,

we outsourced 35 devices to people who undertook to power the device. Now we should have enter a custom server access to all the devices' configuration which is very cumbersome: asking mostly layman people to copy data, flawless.

The solution could surprisingly easy.

1. We should have to be able to export the device's configuration file. (Or just download it from somewhere, just for minimising the necessary development work.) Perhaps this is an XML or TXT file.
2. Then we should be able to simply enter an URL of a remote configuration file on the config page of the device (and in the remote config file, too).
3. The device should automatically reload the remote configuration file with a custom interval, just like the measuring interval. If the remote config file is changed, a Device Restart should obviously be happened automatically.

Voilà, this way, everybody could remote control all their devices. (Of course, this remote config file could be hosted on sensor.community website but it may lead to a huge server load. It's not really necessary.)

In practice, anybody could host the config files on a custom server. For example, our website is www.kerekdomb.hu. Now we could upload all the config files, like:

• www.kerekdomb.hu/airrohr-configs/12342345.xml
• www.kerekdomb.hu/airrohr-configs/43213210.xml
• etc. … 35 files in total, in our case.

and after one and last disembarkation, we, and everybody, could remote-control all the devices, by editing the config files on their server. For an illustration, I faked the config page to show it.

[ricki-z]

What exactly should be changed in the config file?

• The wifi name and password? Without that the sensor can't connect to the wifi network and won't be able to download the changed config. So either it can't connect at the moment or won't connect after the config change.
• The hardware config? Someone would need to make these changes on the decvice itself and could also change the config directly on the device
• Some custom API settings? So we should add this feature because of one group, that seems to change the path of their API regularly?

Beside this: the config file contains the wifi name and password of these users? Do you really think this should be saved on a publicly accessable server?

[pjgueno]

Did you see this: https://github.com/opendata-stuttgart/bulk-flasher And this: https://github.com/opendata-stuttgart/airrohr-firmware-flasher If you have to configure a lot of sensor, you can edit the config.json file.

[Vendrel]

Beside this: the config file contains the wifi name and password of these users? Do you really think this should be saved on a publicly accessable server?

Good point, thanks! It's true, the wifi password won't be changed too often, it doesn't need to be included to the remote config file.

But that's all. It's just about entering data into the configuration of a device far from it.

I've checked out the solutions PJGUENO sent. Now, they make things more complicated, not less complicated.

The question is: Is there any security mine hidden if we read a config.json file remotely? Yes? Okay, then exclude those sensitive datas from the remote config file. Wifi password, don't, okay. :)

The simplest way to resolve remote control is that the device don't just send data outside its subnet but retrieve from outside its subnet.

→ Retrieve: its configuration.

There's an automatic firmware update function in the device, enabled default. No need for 35 disembarkations. Let's include the function to the next firmware update, and voilà. No need to be an expert. Just host a safe config.json file somewhere, and address it once in the local configuration.

We should exclude the wifi config from it? Yes, good point. Then make a wifi-config.json file and a safe config.json file including no sensitive data. This is the same approach of the challenges already taken. We don't need to hack the firmware to enter custom server data because the developers made it simple. Now made this simple, too. That's all.

We're talking about monitoring air pollution. These devices are not playthings, we all know this. Every barrier should be eliminated to prevent NOT using these devices. IF it becomes easy (instead of complicated) to remote control these devices THEN it will be attractive to even more cities and towns, to build a fleet of them.

[ricki-z]

You didn't answer the simplest question: What exactly should change in the config to that there would be the need to upload a changed config file?

There are organisations that use the flashing tool for exactly what you are saying: Building a set of 10 or even 100 devices and flashing the needed settings (excl. wifi SSID and password) for their sensor and API configuration.

[Vendrel]

Oh, yes. Nothing. Just exclude the wifi settings, that's really important.

I'm sorry to tell that but I do it as a supporting effort: It's a management misconception.

The solutions you mentioned (and pjgueno linked) needs a deeper knowledge, Python knowledge. But IF the device is simply able to retrieve its configuration data from a once-specified web address, THEN none of this flashing is needed; even a clever high school student could manage it, on no matter how many devices.

This is an important difference because Python knowledge is a key requirement that must be fulfilled.

Just tell me, which is the simpler option: • hire a programmer to handle the software • make the firmware able to retrieve its configuration file from a specified URL, and then ask practically anyone who can handle an Excel and has (or can learn) basic web development knowledge – comprehends the syntax of the config.json file and is able to upload files to a server via FTP. As I said: this is even a clever high school student. Not a programmer with Python knowledge.

By that Python solution, SC practically placed a mountain-sized barrier before the fleet-building without even noticing how many users won't try to get through, and all those silent masses will • not order a fleet • order a fleet, carelessly, but won't wire them to the custom server because they might already outsourced the devices to their final place, and it's hard to manage to disembark again and make the modifications locally. Like Kerekdomb.hu If I won't tell this then perhaps nobody would tell this. The problem will remain undetected.

You can say that many organisations can use that Python solution. Yes, they can. Other can not. Like Kerekdomb.hu. They are laymen. Sensor.Community simply can not expect it from people who care about air pollution not to be layman, or even if they are layman, then to be able to hire a software developer. There are more silent and invisible organisations who can not do this than those who can. Even a neighborhood may decide to build a fleet. Why should they be able to hire a software developer? Because they have €30/year for a clumsy web hosting with a clumsy web site based on a free template?

Not that it's my duty or mission to extend the number of these device Europe-wide and make them wired into central systems which finally makes the measurements useful. It's Sensor.Community's mission. I simply showed the simplest solution.

[Vendrel]

Oh, there may be a confusion. :) I already described in my first comment what should be changed in the config.json file. This data should be added, as it's shown on this faked example screenshot:

1. An URL the device reads the remote config.json from, and an update interval.
2. AND, as it was wisely suggested, the wifi network data should be separated to a config-wifi.json file.

That's all. Mission accomplished, now even students will be able to manage a fleet of devices remotely.

[pjgueno]

What I have linked is no Python solution but a build software. I have just linked the code in Github but I can provide an app for Mac or PC.

I still don't understand why you would need a remote access to an xml file to do what you explained. What kind of option do you want to update in the config ? The sensor types, the interval etc. should not change imho.

According to my experience, the biggest difficulty for the layman is to write the WiFi credentials correctly. But it is not possible to put it in the xml remote file...

I can show you in a call how the custom and the bulk flashers work.

[Vendrel]

:) Okay, questions (retorical ones, I have no time for this):

1. How to put the custom config.json file on the device, remotely?
2. Where to get budget from to pay You? We are just a neighborhood with a brand name and a cheap website.
3. Why would you do this for free, instead of making the simpliest solution?
4. Why would it to be efficient to put the answers here, and expect everyone in need of the answer to search and find it here?
5. Why would you answer every questions emerged in this topic for each people who ask the question?
6. Why is it efficient for you to provide support for everyone by phone? For free? If not free then you trim the perspectives of the usage of these devices.
7. I have a job, as everyone in this "organisation" has, so it's hard to make an appointment for a support you could provide in a foreign language. There's no guarantee that after we hang up the phone, no other questions emerge.

All above, instead of this:

Where's the efficiency in it? Really. Where?

I don't force it to include non-changing device info into the remote json file. It can be made creatively.

[bertrik]

I'm not a main developer of the firmware (just contributed some tiny pieces), but I am a user and following development. I think it's a bit rude of you to say you have no time, then ask rhetorical questions of the developers and expect them to spend their time on them.

I do think the idea of a remote config is interesting, but I think it requires a new mechanism and probably only really useful in a handful of cases.

[ricki-z]

@Vendrel The repos PJ linked contain the source code of the flashing tool. IF you would have read our instructions then you would know that there are also compiled versions for download. So there is no need to know anything about python. The function for flashing the config.json is beta at the moment as we didn't get enough feedback if there are any problems or if it's okay. You can donload this version at https://firmware.sensor.community/airrohr/flashing-tool/ , filename is airRohr-firmware-flasher-0.3.4-Windows_amd64_BETA.exe (the last file in this directory).

But back to what you asked for. We should add a config option that needs to be filled by the users so that users don't need to change other settings? Most users only need to change the wifi settings (which should not be saved on any public server) and the sensors used in their device. And your way would save what work?

If you build a custom firmware image that includes this setting then you could also build a version where the changes needed by your device version are build in. Or you could use the flashing tool...

And no you didn't answer my question. Why should someone save a config.json on a public server (where would be a chance that someone could change it and with that the settings of hundreds of devices) when there is a much saver way. And all this for a config file that won't change later. Its hard enough to monitor the existing systems, why should we add even more complexity to this? We all are doing this in our spare time.