search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
574 stars 312 forks source link

How to stay up to date with new releases? #92

Open stroebjo opened 7 years ago

stroebjo commented 7 years ago

I just noticed that my InfluxDB wasn't getting any data anymore. The issue was already explained in #80.

But it left we wondering: is there a newsletter or something which I can subscribe to, to get notified about new updates? So I can check what has changed and if I need to update my configuration.

Thanks, Jonathan

rexfue commented 7 years ago

Hi,

i’m using a little python script to check the version string in the .ino file on github and send me an email, if there is a new version. The script is called by cron once a day.

Drop me a mail, if you want to get the script.

Reinhard

On 6. Jun 2017, at 10:44, Jonathan Ströbele notifications@github.com wrote:

I just noticed that my InfluxDB wasn't getting any data anymore. The issue was already explained in #80 https://github.com/opendata-stuttgart/sensors-software/issues/80.

But it left we wondering: is there a newsletter or something which I can subscribe to, to get notified about new updates? So I can check what has changed and if I need to update my configuration.

Thanks, Jonathan

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opendata-stuttgart/sensors-software/issues/92, or mute the thread https://github.com/notifications/unsubscribe-auth/AWTShxJIDvqAYu5b8EEbseV8LRirr_3_ks5sBRFegaJpZM4NxCDy.

rexfue commented 7 years ago

@stroebjo suggested that I should upload that little script here. OK, here it is. To run it, you must adjust your mail data.

Reinhard

checkVersion.py.zip

YNedderhoff commented 7 years ago

This is nice, however, is there also a newsletter or at least a changelog anywhere?

Only the version increase doesn't help much does it?

stroebjo commented 7 years ago

At least you know something changed and yoi can look at the commits/check if everything is still working.

A Newsletter + Changelog definitely would be preferable!

sbamueller commented 7 years ago

definitly a newsletter when the code get updated, also with information aobut the project

On 7. Jun 2017, at 15:33, Jonathan Ströbele notifications@github.com wrote:

At least you know something changed and yoi can look at the commits/check if everything is still working.

A Newsletter + Changelog definitely would be preferable!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opendata-stuttgart/sensors-software/issues/92#issuecomment-306796017, or mute the thread https://github.com/notifications/unsubscribe-auth/AXKtAIvR9qtJOlB0CFMFrmKTbcU05J1Mks5sBqbHgaJpZM4NxCDy.

stroebjo commented 7 years ago

I converted @rexfue's script into an Agent for Huginn which sends an email if a new version is detected. Maybe this is interesting to some.

feinstaub-version.json.zip

hakan42 commented 7 years ago

Maybe it would be best if those scripts were part of the code repository. Could you guys create pull requests to add the scripts? I fear that sometime in the future, this ticket will be closed and then no one will find your scripts 😄

dokape commented 7 years ago

At the moment, i see new versions on the sensor, but do not find any changes in the repository. Also the major changes are not documentated in the versions.md. :-( e.g. NRZ-2017-099 today.

As the work on the firmware is only on a few people, my question is, how can I support them. Is there a beta-branch? I can support with tests, or documentation. E.g. we could make a trigger on the version.md for announce of a new release.

ricki-z commented 7 years ago

The last update was a very fast update (wrong count of seconds since last measurement). I forgot to push the changes.

Adorfer commented 7 years ago

Please commit early and commit often. (and case ouf doubt make branches or use release tags.)

dokape commented 7 years ago

I see, the changes of NRZ-2017-099 are still not committed or documentated.

pathmapper commented 7 years ago

A new firmware version should only be distributed via autoupdate if it is available for everybody here in this repository.

The transparency is very important! I think a lot of users are using the sensor within their home WLAN and there are still security issues like https://github.com/opendata-stuttgart/sensors-software/issues/128 .

Undocumented firmware updates could have a negative impact on the development of this great project.

It would be also good to have a release for every firmware version with a changelog so it is also possible to upgrade the firmware via manual installation.

ricki-z commented 7 years ago

The security issue #128 should be solved mostly. There is only one moment where the password is beeing transmitted in plaintext. But we can't use https for the internal webserver. Self encrypted cert will result in warning in most browsers. That was the first time where the sources weren't updated after distributing the new version via autoupdate. The only change in this version was the counter on the values page. And there is a file Versions.md where the changes are listed. Everything else can be seen in the changelogs of github. Is everyone of you without failures?

pathmapper commented 7 years ago

@ricki-z no bad feeling please, It is about improving this project. I appreciate all the work you are doing, thanks a lot!

@dokape offered help with these things:

I can support with tests, or documentation.

It is up to you if you take it.

Having releases for each firmware available would be also good to step back to a previous version for the case if something is wrong with a new release.

Regarding Versions.md:

Thanks!

pathmapper commented 7 years ago

@ricki-z thanks for updating the Versions.md!

dokape commented 7 years ago

@ricki-z nobody is out of failure. We are all here to help you and ourselfs. Your doing a great job! My programming skills are low. I can read a little bit code. I do a look into the code changes to see if the changes are obviously ok. For our group I make a summary of the changes. My help can also be to look at the versions if a commit was forgotten and remind the programmer. As a help to keep the great code available for everyone. This is, what I can do for the project. :-)

ricki-z commented 7 years ago

The next version will be pushed to master like the versions before. After this all new changes will be pushed to beta branch until the get final. Then the master will be updated before releasing the auto update binaries. So the differences between updates should be listed in the github change log. Is this okay?

Version numbers: To update my test sensors to new beta versions I have to increase the version number. But not all of these versions are published (interim versions, buggy versions, ...).

dokape commented 7 years ago

That sounds good.

As I have not compiled the softtware yet from sources I have some questions for testing the beta ;-)

Would it be a good idea to provide beta-binaries for flashing? If yes, the next questions could be: would the beta-branch also auto-update the beta-firmware? Who will compile the beta-binaries (responsibility)?

Next questions will rise:

General discussion needed.

My Opinion: Registered sensors should not install the beta-firmwares. Values of beta-firmwares should not be stored in the data-base. The firmware should have a value: IS_BETA = YES/NO (or INTEGER: 0 for release, 1-9 to mark BETA1, BETA2...) The behavior of Auto-Update, Versioning, creating values could use this value.

Providing beta-binaries and perhaps a beta-binarie auto-update would make beta-testing be easy. But: where to store beta binaries for download? Not providing beta-binaries and only sources would make more people using the SDK and get more familiar with github ;-)

A lot of question for making a clear transparent crowd-based testing ;-)

What do you think?

ricki-z commented 7 years ago

There are beta binaries on the update server. The update server has a list of nodes that will get those beta updates. All other nodes will get the normal binaries. The USE_BETA switch could be implemented as one of the next new features. And as we have a list of beta nodes we can check that these nodes aren't saving data to the database (or that these data isn't published). For 'alpha' versions (not published as binary) one can disable auto updates. Then the new version needs to be flashed via USB.

dokape commented 7 years ago

My opinions: Alpha-Versions not as binaries is OK Beta-versions for auto-update is great. Having a list of beta-nodes is not comfortable. If someone bricks a nodeMCU (i hope not) he can't take the next for testing, he has to send the ID to someone who can change the list. Why don't do this automatic with the IS_BETA switch? I download the beta-binaries manually and flash it, and at next update, the beta-binaries will be downloaded automatic by the Firmware. So no list has to be updated manaually...

If (IS_BETA !=0) then download release.bin else download beta.bin

Naming could be like this: IS_BETA can be 0 to 9

Version = Version & IS_BETA

Displays Firmware like: NRZ-2017-099 BETA1

ricki-z commented 7 years ago

@dokape I've mentioned this as second point. We need to prepare some scripts for this. Then this feature will be implemented in one of the next versions.

dokape commented 7 years ago

ok.

Where can I download manually the beta-firmware?

ricki-z commented 7 years ago

Beta versions can be downloaded at: https://www.madavi.de/sensor/update/data/latest_beta.bin Beta versions in other languages are named in the same kind as the normal versions, i.e english version is latest_beta_en.bin .

dokape commented 7 years ago

I downloaded the latest_beta.bin I flashed the beta with the ESP-Tool my test-ESP with connected oled, SDS, DHT and BME like on a vanilla nodeMCU. After restart, I had still the NRZ-2017-099 firmware (shows on headers) A second try with pressed flash-button on the nodeMCU had same result. A try with the latest_beta_en.bin hat also the same result. My old configuration was kept. (WLAN and activated Sensors/hardware)

My questions:

dirkmueller commented 4 years ago

@dokape there is a way to install the "beta" firmware from the configuration web UI now itself. how do you want to have the notification about new versions? is this just a "sensor has been updated" email being sent or an opt-in / approval workflow?

DeeKey commented 4 years ago

My opinion is that no separate email needed for notification about new version if there were no security or data reading improvements. But if such change were then an email (preferably based on the language used in sensor HW) is needed to ask owner for an update.

Mostly the initial issue is solved to my mind and can be moved to documentation.