opendata-stuttgart / devices.sensor.community Goto Github PK

When moving to a new place, the data from before and after should be kept completely separated. If I understood right, the sensor are identified by a ID so is there a way to get a new ID?

At the moment the date of the last change is shown. There we could add the registration date.

If you do not add a position (lat, lon), then the [save] yields an internal server error (Status Code: 500).
Error handling and proper message would improve the user experience.

Thanks for the service!

Hello! ich würde gerne meinen Sensor in meine.luftdaten eintragen, werde aber dort seit einigen Tagen mit dem Hinweis: "This sensor ID is already registered." konfrontiert.
Was kann ich denn da genau machen? Habe zur Zeit 3 DNMS laufen und konnte nur zwei registrieren.

Hello! I would like to enter my sensor in my air data, but have been there for a few days with the note: "This sensor ID is already registered." faced.
What exactly can I do there? I currently have 3 DNMS running and could only register two.

I think we can just get rid of all license-related header comments from files and create a single LICENSE file in project root directory. It seems like whole project is uniformly licensed under 3-clause BSD. (Except for /static/{css,js} which is a... well... mix of everything one can imagine...)

Would it be possible to keep the language selected when someone click on the link to our main website?

I see my device send for my BME280:

Pressure (hPa): 102824.97

Which part is supposed to be correct? It should be (Pa) or 1028.25

I'm confused that map shows temperature data, but I'm seeing "No current data are available for this sensor." under temperature/humidity/pressure sensor BME280.

Original version produced an array with 3 fields (country code, part 1 of name, part 2 of name).
Replaced "," with " - " but now it's not translated anymore.

Postal codes can contain (optional) whitespace, hyphens and possibly other non-alphanumeric characters. Openstreetmap geoposition returns an empty result set when the postal code contains any non-alphanumeric characters.

Examples:

51 Street
201-4911
Red Deer
Canada

Kloosterweg 22
6412 CN
Heerlen
Netherlands

I hardware section of sensor registration there is a map. currently it is in some dummy position.
Would be nice to center it on the capital of the chosen country for more user convenience.

Hello,

I have created a new config with 1 sensor.

i want to add news sensors to the configuration but i can't : when i want to edit, we can't add sensor.

So i think to remove and recreate but when i try to remove but :

so if i deleted, i can't recreate for that chip...

Some English strings were updated (mostly due to rebranding to sensor.community).
But translated PO files were not updated accordingly. Because of that some translation strings are not working and there are "holes" of unstranslated English sentences in all languages.

The error message is only saying something about a duplicate ID. This is nearly the same error message than for a duplicate chipID registration. So people are irritated about this.

What are the connection pins of the scd 30 on the particulate matter sensor

After registering a few sensors during a workshop we noticed that the timestamps, dependent on the page being visited, differ. Possible solutions:

• Always indicate time zone when displaying time.
• Always use UTC, or
• always use browser time.

Hi,

I did not receive my confirmation mail, even after waiting for 6 hours.
It seems that the registration process is in a deadlock at this moment: I can't log in, I can't reset a password, I can't re-register...

It would be great to have a backup solution that allows resending of the confirmation mail in case you don't receive it. For example: the reset password flow could contain a mail with a link to start the reset process. Clicking this link could also serve as confirmation.

Kind regards,
Christopher

If the geoposition is entered manually and the address omitted, the form refuses to submit because the address fields are required.

What is the use-case?

• user does not want to disclose their home address, let alone have it stored in a public database
• the sensor is not installed at a proper address, for example a lamp post, in a park or in a forest

I get most time no data from server, only the empty map.
A self registration is not possible because of server timeout.

Any issues with server overload?

Thanks,
Michael

Combining the particle measurement with a noise sensor leads to problems with the amount of sensors to be registered.
Please add more possible Sensor types.

If SDS011 and Noise is selected, then no DHT-(or maybe BMP/BME) Values are sent to sensor.community.

Not needed:
How much industrial activity is there within a 100m radius?
How many private stoves or fireplaces are within a 100m radius?
How much traffic is there within a 100m radius?
These inofrmations get be retrieved from external sources.

https://devices.sensor.community/sensors/<12345>/data shows

10.18 hPa for air pressure and 10.24 hPa for air pressure at sea level.

That should be 1018 hPa and 1024 hPa instead.

Hi,

ich hoffe, ich bin hier an der richtigen Stelle mit dem folgenden Problem:

Ich habe heute zu dem bisher laufenden Paar SDS011 & BME280 einen SHT35 hinzugefügt und in der Konfiguration aktiviert (Firmware: NRZ-2020-130-B6/DE). Ich lade zu madavi, sensor.community und opensensemap hoch. In den aktuellen Werten wird der SHT35 angezeigt. Auf maps.sensors.community werden aber nur Feintaub und die Werte des BME280 angeboten. Auf https://devices.sensor.community/sensors sehe ich keinen Weg, einen dritten Sensor anzumelden. Im Debug Fenster taucht folgende Meldung auf:

## Sending to sensor.community - SHT3x
Request failed with error: 400
Details:["sensor could not be selected."]

Was mache ich falsch?

My P1 and P2 values are displayed on the map on sensor.community, but not the humidity and temperature. Looking at the dashboard the values are present though:

I can also read them through the API: https://data.sensor.community/airrohr/v1/sensor/71307/

I had my sensor(s) marked as indoors, but changed it again for testing purposes, because I thought it could maybe prevent the indoor values from showing up on the map - does that make a difference?

EDIT: If this is the wrong repository to ask this question, please feel free to move the issue.

Current devices.sensor.community user config sensor data nicely displays all sensors of the node.

Missing is the node its firmware release version that was used to publish this data.

As there was a sensor display strangely high PM values for a few weeks (starting June 28th), I was wondering which sensor was running which firmware version. Though I could not find the running firmware release at devices.sensors.community it's node.

This Feature Request is to include such information at https://github.com/opendata-stuttgart/devices.sensor.community/blob/develop/webapp/templates/my-sensor-data.html.

Seems like Pipfile is missing some dependencies defined in requirements.txt. (ex. Flask-Security - a direct project dependency, while also containing some second-level dependencies like asn1crypto)
Additionally, as requirements.txt now does >= version match, newest version of psycopg2 fails to install in Docker environment due to missing postgresql headers (psycopg2 used to default to binary build, now this is split into psycopg2-binary package, it seems) - replacing psycopg2 with psycopg2-binary in requirements.txt solves this partially in that case.

Generally speaking, we should always have some locked versions, that could then be upgraded. I haven't used Pipfile so can't really say anything about it, if Pipfile.lock really locks proper version, then we can fully migrate to Pipfile. In that case we'd have to re-add missing dependencies from requirements.txt into Pipfile and modify Dockerfile to only use Pipfile/pipenv.

@ohheyitsdave can you elaborate on that?

Mit Freude habe ich gelesen, dass die Registrierung und Konfiguration der Sensoren auf https://meine.luftdaten.info nun selbst vorgenommen werden kann - vielen Dank dafür!

Interessanterweise sehe ich in den Einstellungen der Sensortypen auch den SHT31/35, den ich in meiner Haussensorik gerne verwende, da er gegenüber dem BME280 z.B. einige Vorteile im Aussen-Bereich hat (die Luftfeuchte geht nicht auf 100% und der Sensor kann bei Bedarf beheizt und getrocknet werden. Hinzu kommt, dass insbesondere der SHT35 deutlich genauer misst als der BME280, was aber für diese Anwendung nicht relevant ist).
Mit der Auswahl des SHT3x und der PIN 7 stehe ich aber vor dem Problem, dass die Konfiguration insgesamt nur zwei Sensortypen umfasst dass ich damit zwar Temperatur und Feuchte als SHT3x kennzeichnen kann, es aber nicht mehr möglich ist, neben dem Feinstaubwert auch noch den Luftdruckwert eines BME280 zu senden. Beim Versuch, zusätzlich zu Temp/Feuchte mit PIN=7 und Feinstaub noch den Luftdruck mit der nicht eingetragenen PIN=11 zu senden bekomme ich diese Antwort vom Server, da offensichtlich nur die zwei in der Konfiguration eingetragenen PINs akzeptiert werden:

HTTP/1.1 400 Bad Request
Date: Sun, 05 May 2019 11:54:11 GMT
Server: Apache/2
Allow: POST, OPTIONS
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json

21
["sensor could not be selected."]
0

Testweise habe ich unter Verzicht auf Feinstaubwerte als ersten Sensortyp den SHT31 eingetragen und als zweiten Typ den BME280. Damit können Temp/Feuchte mit PIN=7 und Luftdruck mit PIN=11 gepostet werden, die Werte werden auch vom Server akzeptiert. Auf maps.luftdaten.info werden mit dieser Konfiguration die mit PIN=7 gepostete Temp/Feuchte Werte nicht dargestellt, sondern nur der mit PIN=11 gepostete Luftdruck.

Mir ist klar, dass es den Use-Case mit der (aktuellen) airrohr-firmware nicht gibt, für Anwender mit eigener Firmware wäre es jedoch geschickt, wenn insgesamt mehr als zwei Sensortypen konfigurierbar wären, so dass für Temperatur, Feuchte und Luftdruck unterschiedliche Sensortypen akzeptiert würden.

At the moment the default country is Aruba, if the country can't be determined via prefered language settings.

Your registration form mentions stoves and fireplaces ( line 80 and 92 of form.py), but you don't mention other wood-burning sources of PM like barbecue and burning vegetal waste in one's garden. These event creates a high peak of PM during a few hours, and/or contribute to the accumulation of particles during specific weather.

I live in a small French city, which has no industry, low traffic, no highway... Most of the pollution comes from people fires: during spring and summer, it comes from barbecues, people burning their garden waste or farmers burning vegetal waste. These come on top of to the chimney smoke in winter, so it smells like burning several times per day, during the whole year.

To help interpret the data, you could simply add this missing question:
"Do people burn vegetal waste in your area or barbecue ? 1 = very little, 10 very much."

Adding an exsiting chipID should show a message that this sensor is already registered.

To "delete" a sensor we could set it to inactive and add a prefix "deleted-" to the email field in the API database. This will take the sensor from the user list of sensors, but we could restore it.

Currently selected locale/language can be overriden using ?lang=xx request argument. This setting is stored in user session, and can be cleared using ?lang= (empty argument)
https://github.com/opendata-stuttgart/meine-luftdaten-info/blob/0b45bdab7fcc44c01938760d2882ac7f073afb74/webapp/babel/__init__.py#L15-L20

This functionality should be exposed in user interface, for example in upper right corner, or in footer.

There are some mistakes on the French translations but I can't find the original strings in the file: https://github.com/opendata-stuttgart/meine-luftdaten-info/blob/develop/translations/fr/LC_MESSAGES/messages.po

I copy them here so it will be easier for you to copy them:
Adresse Email
Mot de passe
Garder ma session active
Se connecter
Cela peut prendre jusqu'à 30 minutes pour recevoir l'email d'enregistrement.
Si vous n'avez pas reçu d'email, merci de vérifier de la catégorie Spams.
S'enregistrer

Also, I have created a pull request on the wrong reposetory for the French translation: Informatic#1
Is there a easy way to send the pull over to you or should I create a new pull request from scratch (I have seen that all the strings have been translated but some could be improved).

Where can I find the Sensors level above ground in data base?
I need it for some statistic assessments.

Hello,
Meine.luftdaten.info/devices.sensor.community doesn't work now. - Service Unavailable Error
Could you fix it?

Some people (especially Smogomierz user until now) copy the chipID from a text that contains special chars afer the chipID. This leads to some strange side effects (beside the API not receiving the data)

Internally Hardware configuration part of sensor registration/settings form supports arbitrary number of sensors, but right now only 2 sets of fields are rendered. This needs a couple of lines of javascript to handle special button that'd dynamically clone one of the rows and replace -0- part of all name, id and for attributes of <input> fields with consecutive numbers.

Related code: https://github.com/opendata-stuttgart/meine-luftdaten-info/blob/c92728bfa7e91c6803b3ad3f88969b24bc20bcda/webapp/templates/sensor-settings-form.html#L29-L36