Release source code? about ispindel HOT 12 CLOSED

sources are online

from ispindel.

Sorry for late reply.
For such 'open' projects I really don't like adding closed code that I can't edit or review. Haven't uploaded the BIN yet (not all parts in stock) but it look's all in German to me. Also I don't want to send the data to ubidots or some other provider.

Really like the project, but for me I would like to view and edit the code instead of building a black box without knowing what's happening inside the device and my data.

from ispindel.

Yes I would also like the source code to be open so us DIY-ers can change the code to our specific needs, help fix bugs and learn how this thing does what it does :) I also don't want to have to put my data in ubidots, instead I'd like it to post the data to my own web service.

from ispindel.

Hi,

Currently we are in the Test phase, and I like to get feedback from the standard setup. Thats why I wait to release the source to avoid unhelpful noise.
Which features are you missing currently?

from ispindel.

Thanks @koffienl @jaapz for your interest in the project!

To answer your questions:

• The firmware is entirely in english, the documention is being translated WIP
• There is WIP to support other services than Ubidots, like the #3 universal HTTP Connection. If you have other needs where you can't use this approach, feel free to open an issue and maybe even provide code how the transaction should look like
• There is nothing like "Blackbox" with this project. As being said, the source code is going to be released once the test phase is settled and the hardware and software is considered stable. Otherwise, the support is not possible to handle.
• The code is already being shared among contributors that help to get the project going on by helping with translation, testing or donating to hardware. To put the things right, I have no commercial benefit of sharing this idea, the project and the software but having to spend a lot of time, money and efforts to provide a working solution. So there is no obligation to share other than for those who contribute to the project in contrast to the people who want to to "their thing" which doesn't help at all but creates just more work.
  Fair enough regarding the contributors, right?

from ispindel.

Thanks for explaining.
I understand your point of view, but (and I am sorry to say so) I have zero interest in closed code without knowing what I'm installing or what it is doing. For me it still would be installing a black box and searching in the dark when things don't work as expected. I'll just have to reinvent the wheel to get it working by myself.
I truly believe the project could benefit from being open from the start. Everyone can see the code and contribute enhancements to the code.
Yes you would get a handful of 'noobs' just opening tickets "hey, it doesn't compile. HELP!" but the type of project (you have to have some knowledge of ESP/arduino simple hardware and connections) would bring other people with knowledge of programming, ESP8266 and related stuf.

So there is no obligation to share other than for those who contribute to the project in contrast to the people who want to to "their thing" which doesn't help at all but creates just more work.

That's the other way around ;) You keep it closed and say "only who contribute can see the code". How do you expect someone to contribute when the source isn't available?

from ispindel.

How do you expect someone to contribute when the source isn't available?

There are various ways of contributing to the project:

• testing and providing feedback
• translating documentation
• creating documentation
• providing features
• donating

Feel free to share your contribution and I am happy to share early code access to you.

from ispindel.

koffienl, you might wish to wait until the SW is out of alpha test mode. Just like everybody else, including me. There is an entire bunch of people waiting eagerly.
universam1 is doing a fing heck of a great job. But if you - as you say- have zero interest, just ignore the project for a while. What's the issue?

from ispindel.

koffienl, you might wish to wait until the SW is out of alpha test mode. Just like everybody else, including me. There is an entire bunch of people waiting eagerly.
That's what I mean : opening the code and let others contribute openly will speed up the project.

I already see stuff I would like to add/change (but not necessarily interesting for others):

• OTA firmware update without taking the device out of the fermenting beer
• Local webserver showing the measured info, perhaps in a graph
• Save all the measured info into a local JSON file as backup
• Make deep sleep an option
• Let the ESP connect to some webservice / API after returning from deep sleep to figure out if it still needs to be in deepsleep (so you can set a var somewhere in the network, the ESP powers up and understands it shouldn't go into deepsleep) so you could change some settings or update the firmware with OTA

But if you - as you say- have zero interest, just ignore the project for a while. What's the issue?
Oh I definitely have interest in the project, just not in closed source.

But hey, I'm not here to bash the project - I wish @universam1 all the best for this project, a lot of homebrewers can't wait to use it.
It's a great project with lots of potential, unfortunately that potential is not fully used because of only providing BIN files and mainly communicating in German IMHO.

from ispindel.

Lets talk:

OTA firmware update without taking the device out of the fermenting beer

thats possible

Local webserver showing the measured info, perhaps in a graph

already implemented (no graph)

Save all the measured info into a local JSON file as backup

?

Make deep sleep an option

Thats the reason for to keep it NDA, because people without understanding of the fundamental principle of this project will "dead modd" it with these approaches. The deep sleep is the soul of being able to run this project at all and there are a lot of tricks around it. I'm eagerly interested in a good reputation with proof of working before all this breaking changes are going to happen. Sorry to say it this way, but do the maths!
Currently, the runtime with one NCR18650B is up to 3 months @30min updates, without deep sleep you wont reach one single day!!

Let the ESP connect to some webservice / API after returning from deep sleep to figure out if it still needs to be in deepsleep (so you can set a var somewhere in the network, the ESP powers up and understands it shouldn't go into deepsleep) so you could change some settings or update the firmware with OTA

This is also already implemented and ready to be used to change update interval on the fly. Though tests have shown that this again increases power consumption with around 100% so not enabled currently.

mainly communicating in German IMHO.

Here is the point, I'm happy with contribution by translation, so feel free to go ahead!

from ispindel.

For graph you could something like this: http://zooi.oostindie.com/images/977capture.png
(perhaps a bit of overkill, but this screenshot is from a brewcontroller I'm building, but it's about the graph).

ave all the measured info into a local JSON file as backup
?

Let's say your local wifi has a power loss in the night (or your ISP, or ubidots) and you loose your history. If you write all the measured data to a local (JSON) file you have a backup of the history of all the data.

Thats the reason for to keep it NDA, because people without understanding of the fundamental principle of this project will "dead modd" it with these approaches. The deep sleep is the soul of being able to run this project at all and there are a lot of tricks around it. I'm eagerly interested in a good reputation with proof of working before all this breaking changes are going to happen. Sorry to say it this way, but do the maths!
Currently, the runtime with one NCR18650B is up to 3 months @30min updates, without deep sleep you wont reach one single day!!

I understand that, bit it sounds like the point of view from the side of a manufacturer. Shouldn't the people with understanding of what they are doing have the option to choose what they want? Especially in the debug fase when they are building and finetuning the device? ;)

This is also already implemented and ready to be used to change update interval on the fly. Though tests have shown that this again increases power consumption with around 100% so not enabled currently.

Of Course, doing a extra HTTP call when coming out of sleep will use some extra resources. So make it an option.
Not sure how all settings are saved on the ESP currently : in EEPROM or in a config file in SPIFFS ?

Here is the point, I'm happy with contribution by translation, so feel free to go ahead!
Like I said, my German is very limited. I can understand some basic stuff but not enough to understand everything.
I'm happy to support/help , but it looks like tere is a lot of 'resistance' . Your project, your code, I understand that. Just saying you would probably get better code, ideas and input if people could see what the code is doing.
I might have some nice ideas and also would be able to fit it in the code (I have done some little pojects myself) but probably not the best code in the world ;)

from ispindel.

Great, thanks!

from ispindel.