WebIOPi future

[trouch]

Dear fans,

WebIOPi is alive for more than a year now, and last release was 8 month ago.

It has been used around 150000 times by 50000 users, I never expected such a success !

I really apologize for being away from this board all this time.

I would like to thanks the most active users on the webiopi group for the help they provided :

1. me (285 posts)
   
2. Toshi B. (108)
   
3. Andreas R. (73)
   
4. Robert M. (49)
   

I also would like to thank people who gracefully made donations to me since the 0.6 release.

The total received is exactly 198.40€ with 10 donators, including a single 100€ donation on last week.

Not that bad, I really appreciate every single donation, but it's not enough to push the gear up.

I'm still thinking to resume the WebIOPi development, but I'm not sure where to go.

The main objective is to provide a multi platform solution, compatible at least with Raspberry Pi and Beagle Bone.

There is also an old roadmap with many features : https://code.google.com/p/webiopi/wiki/ROADMAP

As I'm not good at UI designing, I may refocus on the Server design, features and APIs.

I'm also facing few issues related to protocols handling and the no-library current design.

This topic intend to group users requests to watch interests and plan the webiopi next steps.

Feel free to tell how do you use WebIOPi, difficulties encountered and missing features.

If you wanna help and already looked in the sources, you can contact me directly on my mail.

Depending on feedback, I will then decide to resume or not and what to do.

Eric / trouch.

[Andreas Riegg]

Hi Eric,

 

happy to see you here again.

 

I will think about pros and cons and what can be done with limited development effort and maybe the help of some people active here to keep WebIOPi futher going. I will do this open for all here as long as the discussion keeps being fair and realistic (posts like "I would need those 100 neat features additionally asap and I'm really waiting now for you to implement those asap for free" or "Why don't you make WebIOPi so fool proof that every web noob you can find out there can use it in 5 minutes?" are those that I would not find fair. If this happens I will send you my further thoughts via direct mail.

 

The main questions that I see are:

 

- What are the real uniques features of WebIOPi that make it so valuable and how can these features be extended with limited effort (taking into account that the donation thing won't be much different in future)?

- Which architectural constraints can be accepted to reduce effort and dependencies (e.g. no further HTTPS and authentication addons, use WebIOPi directly only in secured LAN segments and do external access via Reverse Proxies or VPN tunnels, maybe provide documentation how to do this)

- Which dependencies of other libraries (C or Python or ...) could be accepted and maintained because they provide very important functions that can't be implemented within WebIOPi for sheer effort reasons?

- What can be improved by just better documentation and examples (maybe provided by someone else than you) instead of making code and tools more sophisticated, secure or fool proof?

- How important are clients or client libraries in X languages?

 

Andreas 

 

 

[Toshi Bass]

Hi Eric

I am also pleased to see you back.

It would be a great shame if you decided not to resume development of WebIOPi.

In general I agree with Andreas post in particular the following points.

Its no use making Webiopi into some "fool proof software" I suspect like me, most of the noob type users want to learn by example, not have built in ready made solutions for every conceivable situation, personally until 8 or 9 months ago when I purchased a raspi, I had never written a line of code so what I have learnt is from a desire to find solutions to my home automation ideas, the Raspi & Webiopi has given me the tools to achieve this, 

Examples for Raspi and Python can be found by googling, however not so Webiopi, if I was to add up the total time I have spent in complete frustration just making trial and error guessing on how a function etc should work or the correct syntax that is needed in Webiopi it would equate to around 70% of the time I have spent with Webiopi, in one way this could be classed as a good thing I guess, learning curve and all that, but just a little better documentation with some fundamental examples would have saved so much of my hair, in reality my project has advance well now, but I am still doing things like switching i2c expander output pins by first switching say gpio35 in Webiopi then in python checking the state of gpio35 and toggling the i2c pin, I am sure theirs a better way but I don't have the ability to understand how, without just a snippet of an example, that being said I am happy with the results that I have achieved and all thanks to Webiopi.

I agree with Andreas external access should be via Reverse Proxies (whatever they are) or VPN tunnels, documentation on how to do this would be great, I have dabbled with openvpn but found out that my virgin-superhub is not so super, it doesn't work with that, so it looks like I need to purchase a new wifi router.

Not wanting to be one of the 100 neat feature gang, but if I had a wish list it would be to incorporate edge detection support, part of my project monitors an existing wired security alarm system like pirs, door and window magnetic reed switches etc and having to continually poll the i2c input pins that are connected to the zones to look for changes of state slows the response time for everything else, I am sure edge detection could be very useful for numerous applications. 

The rest I leave to your better judgment, but "decide to resume".

Toshi 

[Todd A. Cudaback]

Eric,


I choose WebIOPI because of it's simplicity, support and examples. I knew nothing of the raspberry pi a year ago. I happened across you article in Magpi and thought, WebIOPI would be a great way to learn and get familiar with the possibilities. The experience has provided all of that and then some. Thank you for me it has been a great platform.

Moving forward please consider these ideas:

1. Keep it simple:
The appeal, from my view point, is people looking for a platform that is easy to learn and incorporate with good support. So far it has appeared that some individuals have really taken the ball in your absence to help people. This has been a good thing, you know have some trained coaches who are willing to learn more :) Maybe create a forum for the dedicated individuals that are fielding questions and trying to help others.

2. Consider a book: "WebIOPI for dummies" I know you and others fielded questions that were easily found by just using the resources that you provided. Create some learning exercises like "Cambot" I learned so much from taking it step by step. If there was a book that I could have bought I would have bought it. Still would.

3. Keeping the focus on whats popular:
It seems that the attraction has been mostly with home automation. Hot topic for experimenters. Robotics is another one, look at a recent issue of Linux Developer magazine. Raspberry Pi is a shaker and a mover and WebIOPI was on the leading edge of a huge wave don't leave it in the foam but don't drown yourself either.

4. Cash flow is what is going to keep you motivated:
I know open source is the wave these days. I have my own issues with my internet talk radio show and getting it to cash flow. There are enough members in this group that I'm sure we can come up with some ideas. The posts are being searched daily that's evident, more messages about providing support for WebIOPI and helping fund it might be a solution. One idea that just popped into my mind is; What about a WebIOPI experimenters shield?


Just some of my thoughts get another article in the new Raspberry Pi GEEK magazine I'm sure they are hungry for good content, that will keep up a good head of steam. I'd bet that some of the members of this forum would chip in to help with it. I know I would.

WebIOPI Fan and user

Todd Cudaback

---

From: trouch <tro...@trouch.com>
To: web...@googlegroups.com
Sent: Tuesday, November 26, 2013 2:00 PM
Subject: WebIOPi future

--
You received this message because you are subscribed to the Google Groups "WebIOPi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webiopi+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[trouch]

Thanks guys for your feedbacks.

Here you'll find few answers to your questions.

Objectives

In the past, WebIOPi was entitled "REST Framework for Raspberry IO".

I always tried to keep it as a main objective, and I think it's still true.

The second objective was to write something without dependency.

WebIOPi is targeted to people wanting to build IoT apps without worrying about networking, and noobs-boring stuffs.

It's not supposed to be plug&play, but more in the Raspberry spirit : the user learns how it works and what happes

But it involve different things : Python, Javascript, REST, and HTML with a particular set of functions. It's a lot !

Documentation

I understand WebIOPi can give headaches to noobs and I agree the wiki misses few documentation and examples.

Coding and debugging WebIOPi is not easy, but there is few things to help it I should add on the wiki.

I thought about writing a book, but I never took time to do this even if I was in touch with a publisher.

HTTP/Proxying/SSL

Reverse Proxying is limited with WebIOPi as the root location must be proxied. It can be fixed by changing URI patterns.

Giving a more secured access (HTTPS, DTLS) natively is certainly a must have for next releases. But self-signed certificates can be hassle to handle with some browsers for noobs.

Access from Internet should also be simplified or more documented but it depends on your router.

I'm also thinking to provide a public service that webiopi will connect to in order to be accessible from Internet.

But this has a cost I cannot afford on my own.

Real-time IO

Edge-detection/interrupts is also on high priority, but there is few issues to solve.

First, on low-level, then I will need to add Web-Socket.

Adding WS may break the 0-dependency design, and pop others issues...

Clients libraries

In my opinion, Python and Javascript Client are mandatory. But JS one should be rewrite to remove HTML things.

Financing

I tried to get time at my job to advance on webiopi this year, but did not succeed.

If I can find some financing, I will be able to take unpaid days from my job, which could speed up the dev by ten.

With a full-time work during 2 to 6 months, WebIOPi should be a nice piece of jewel.

Right now, I may resume the dev in January, at a slower rhythm than before.

About this topic, we'll see. As I now have more than 150 unread messages here, it will be easier to ignore if it goes wrong ;)

Hope you'll find this post useful,

Eric.

[prairietech]

Eric,

As a complete noob, webiopi has taught me more about RPi, html, gpio, javascript and the list goes on and on.

I'm so new/green to all of this, giving you any ideas for future development of webiopi would be laughable.

However the most important thing to me, is the technical support from this community. I would love to read more about users projects involving webiopi. Coming up with my own design is a huge task. But seeing someone's project gives me ideas how I can mold it into something I can use.

I'll be making a financial contribution as soon as I can find the Pay Pal button.

Webiopi has been the most fun I have had in a long time!

Randy

[Jack Sparrow]

Hello,

Just some thoughts on the future of the application.

Clearly if you had funding you would like to spend more time improving it.
- Have you thought about charging a small fee just say $5 and making it available through the Raspberry Pi store only. A user base of 50000 people should be able to contribute enough to make this venture worth your time.
- Could you have an add supported homepage like Raspbmc?
- Can the Raspberry Pi foundation help with some funding or even some programmers? I think that they should as your software is a great tool for learning with the Raspberry Pi and this is what they are all about? Correct me if I am wrong but I believe that they haven't even featured it on their blog yet(Is this correct?).

Finally how do other programs like Raspbmc manage to do it? Are they a group of programmers all working together doing what they can or are they made by people like Bruce Wane and Tony Stark who have unlimited cash resources and do it just because they can?

I think that a change of approach and using strategies that have worked for other great applications might be the way to go.

Thanks for all your hard work Eric.


This is a great application and I believe fundamental to the purpose of the Raspberry Pi. I can't see why developing this it all has to be left to Eric.
 

[trouch]

thanks for your feedbacks guys

few answers : 

- limiting install to the pi store is not acceptable as many people (like me) use the Pi headless, without X server.

mandatory pay version is not acceptable neither. But I can make a download page with a donate button.

- webiopi has never been featured on the official blog. I already mailed Liz Upton few times but never got any anwser.

- it's hard to compare webiopi to raspbmc. Sam is a student and he started raspbmc on his own. Raspbmc is more a well-integration of existing solutions (debian, raspbian, xbmc) than a development work. But it also requires a lot of time.

About the raspbmc use, you download, start and play, it works. Receiving donation is then certainly easier for him.

Using webiopi can be frustrating, and people don't make donation when they are frustrated. That's it, the webiopi quality is not enough, or at least the documentation.

few options :

- Providing a ready to use SD card image and a nice admin web UI to easily use connected sensors, boards, etc, should avoid many frustration, but it's a really huge work.

- I'm also thinking of some optional pay addons for extra features, but I want to keep the core/base framework free & open.

- mobile applications with both free and pay version. looking stats, Android is more used than iOS.

--

[Mitja Vukelic]

Trouch,

WebIOPi is great peace of software, great idea and great job.  I will try to make another Java and C# API for it, maybe some nice API will help people to use it as backend for their project. 

WebIOPi is core of my final work as BEng in ICT - Telematics, remotly controlled R/C car. As you know I used my Java API.

When somebody tells that it's not for noobies , sorry but I must desagree. My first python programming experience was WebIOPi and it's very easy to understand how things work :D . Following your wiki I manage to communicate over serial with Arduino using WebIOPi on 15 minutes.

As I say before, I will do my best and try to keep WebIOPi as backend in all my future project.

Sorry for bad english :D

Greetings from Croatia, and thanks for great job  

Dimitrij Vukelić

Napomena:
Ova elektronička poruka i njeni prilozi mogu sadržavati povjerljive i/ili povlaštene informacije, a namijenjena je isključivo za upotrebu naznačenog primatelja. Ako ste ovu poruku primili greškom, molimo Vas da o tome bez odlaganja obavijestite pošiljatelja, da uništite izvornu poruku i njene priloge i bez odlaganja poruku i njene priloge izbrišete iz Vašeg sistema. Neovlaštena uporaba, distribucija, otkrivanje, umnožavanje ili izmjena ove poruke je zabranjena. Pošiljatelj ne daje niti ne prihvaća pravno obvezujuće izjave putem elektroničkih poruka osim ukoliko drugačije nije izričito navedeno. Budući da komunikacija internetom nije zaštićena, pošiljatelj ne prihvaća odgovornost za sadržaj ove poruke, kao ni za eventualnu štetu nastalu zbog zaraženosti ove poruke virusom ili drugim štetnim programom, te zbog eventualnih tehničkih problema prilikom dostave ove poruke

[Andreas Riegg]

Eric,

 

Just here some thoughts about the funding topics. Concerning the technical topics, I will post my thoughts in another post such that these both aspects are not completely intermixed.

 

Well, funding free and open source software (FOSS) is a non-trivial task. Some models that exist are:

 

- Being sponsored direct or indirect by a big IT player. In most cases, the developers are just employees of those companies and the work they created is "donated" to the community for free. In some cases also direct financing took place like the one Eclipse Foundation got by IBM. However, this is out of reach for WebIOPi and we can see in the latest time the trend that this kind of funding will be reduced anyway because FOSS is felt to be cannibalizing too much software related revenue of those IT players.

 

- Being sponsored by a public funded research project like those from the EU. Still very important and well working, but also out of reach for WebIOPi as far as I see unless you have some very close contacts and working relationship to any university. Btw. many "projects" or "components" for the Raspi have some close relationship to universities (but this does not mean that they are funded by the EU, but they live in the academic world).

 

- Crowdfunding models like those from kickstarter. Works, but typically more hardware- or media/art-oriented projects get funded, software is also there but at a more rare base. However, look at their site and you will find even some sucessful funded projects for the Raspi which is amazing. Maybe this is worth a try for WebIOPi, maybe some of us can help you creating the "text" work that is needed to get the project documentation for the kickstarter site funding advertisement. Achievable funding amounts for smaller proposals range from 5.000€ to 20.000€. This is not that much but fair enough money to retire 1 or 2 months from job (if you want) and bring WebIOPi a big step forward.

 

- "Fly-by" funding like the donation-button you use or the "Freemium" stuff that you can find in the app stores. You get basic functionality for free and additional functions for additional fees. Or, more common, you get advertisements and get rid of them by paying a bit. Well, the financial results of your funding-button you know best. Basic and paid premium functions for apps is ok, but the premium functions must be really present which is hard to achieve at all for a product that has its real strengths in the headless server world. And the get-rid-of-advertisement ones typically dont't really work well rising a lot of money, most people just accept the boring advertisements and catch some frustation about the app and its developer, but that's it. Plus, a short look at the Google Play store shows that most of the Apps related to the Raspi are free. And the "Freemium" ones cost around 50 ct, so even if you have 1000 people buying this, you will end up with some 500€, how far can take you this amount? If we look at the statistics, only a very small number of developers really make a reasonable amount of money with apps business today, most don't. It is a little better in the Apple world, but not dramatically. And, keep in mind, the typical Apple product customer will just stay within the Apple ecosystem and buy Airplay-enabled products off the shelf, most of them will even never have heard anything about the Raspi nor try to solder some electronis by themselves. Bottom line: I don't expect that much funding from this kind of efforts.

 

- Non-financial funding by just providing collaboration and development support. This is how most FOSS projects at least started (and most of them still are). This is also what I did for WebIOPi (only a little bit). Its obvious that delegation of every subroutine to another person makes no sense and that someone must play the role of the chief developer. But almost every software project can be divided into smaller parts that can be worked somewhat independent on. Maybe this is also a possible way forward for WebIOPi. Someone can have a look at the python server kernel and the protocols like https and websockets stuff, others could provide just much better documentation, how-tos and examples (many pieces already exist in a lot of posts here), others could broaden the hardware drivers by exposing more features from the various chips that have already basic support and others could take care over some of the client libraries (Python, Java, JScript). Why not just opening a new discussion thread with the purpose that individuals can post concrete help they would be willing to provide. After a while, you could check the help offers and decide if this can make sense or not.

 

I would not expect funding from the Raspi Foundation. Their main "mission" is education in IT (especially of young persons) which is a very admirable attempt that I appreciate very much. Yes, you can learn a lot of things when working with WebIOPi, but its main purpose is not in the education area and that may also be the reason why the foundation may behave a bit unresponsive to publication efforts for WebIOPi on their official website.

 

Anyway, I'm sure we have at least two somehow realistic possibilities that may help to let WebIOPi move on.

 

Andreas

[quad...@yahoo.com]

I've been following all the work people have been doing with WebIOPi and I'm appalled that Eric has received less than $300 in donations for creating WebIOPi.  I decided that it's time for me to step up and make a donation and I found a web site where I can donate to Eric through PayPal by using my credit card.  But, I'm confused by all this discussion about how hard it is to donate funds to Eric and this makes me fearful of making a donation on the PayPal site.  Is that site a scam?  If it's not a scam, then what is the point of all these discussion about how we can make a donation to Eric for the work he has done, when all we have to do is shut up and go make a donation through PayPal on the web page he has already set up to accept donations.  If Eric will confirm that https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=79EM7ZV9FQ4HU is a legit site where funds can be donated directly to him, then I'll

gladly make a donation to him today. 

[quad...@yahoo.com]

I've been following all the work people have been doing with WebIOPi and I'm appalled that Eric has received less than $300 in donations for creating WebIOPi.  I decided that it's time for me to step up and make a donation and I found a web site where I can donate to Eric through PayPal by using my credit card.  But, I'm confused by all this discussion about how hard it is to donate funds to Eric and this makes me fearful of making a donation on the PayPal site.  Is that site a scam?  If it's not a scam, then what is the point of all these discussion about how we can make a donation to Eric for the work he has done, when all we have to do is shut up and go make a donation through PayPal on the web page he has already set up to accept donations.  If Eric will confirm that https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=79EM7ZV9FQ4HU is a legit site where funds can be donated directly to him, then I'll

gladly make a donation to him today. 

On Friday, November 29, 2013 6:15 AM, Andreas Riegg <andrea...@googlemail.com> wrote:
 

[prairietech]

I used that button to make a donation and later received an acknowledgement from Eric via email.

Randy

[trouch]

Well, this topic was not intended to find funding but was more about tech specs, then to see if funding is required.

I really appreciate this consideration from all of you. And you are right, getting some fund will definitely help to go further with WebIOPi.

- IT player sponsoring :

My company is one of the biggest IT in France, I'd really like to get sponsored by, but it's complicated. I still have 1 thing to try up.

- Public funding :

Seeing how some EU projects work in my job team, this is not an option for WebIOPi.

- Advertising :

It works well on mobile application if peoples (re)use it enough.

But I don't want to play cat&mouse with ad-blockers on websites and webapps. That's why there is absolutely no ad on my blog.

- Donation :

It still the simplest way to get fund, but I cannot manage any schedule.

- Freemium :

I'm also thinking about it, but I need to find out which feature must be paid.

- Crowdfunding :

I'm really thinking about it, but WebIOPi needs to be more sexy, more packaged and provide something more. I have an idea to try but I can't speak here. But I'm afraid of consequences, I may need someone to help me manage the fund if it success, at least for legal reasons and taxes. If I need to make a company, at least 50% will go in taxes and functional stuffs.

- Code contribution :

As I said in my original post, feel free to contact me directly if you already looked into sources and wanna help.

It's something I appreciate as much as donation. It works well for some stuff, just like Andreas and Stuart did for some device drivers. But I actually have difficulties to delegate others things. WebIOPi is my baby, I'm hard to please, and I'd like to keep it mine. Moreover, I feel embarrassed, because I consider that important contributors should gain a part of donations. Then, how much to pay back for contributions ?

Nevertheless, I'm considering to separate UI/JS and Server to delegate the UI/JS side.

- Selling preloaded SD cards

Another option I may consider ?

- Pi Foundation funding :

I agree, they have their own problems. But a highlight on the blog may help.

--

[trouch]

quick answer : yes, it's the good link, not a scam.

actually, you have two places to find it :

on my blog, left menu, http://trouch.com

on the project site, page's bottom, https://code.google.com/p/webiopi/

Eric.

[trouch]

Questions about my donate buttons :

* The recipient address is tro...@trouch.com, my public mail I use for my blog, webiopi's google code, the google group... It's a dedicated paypal account.

=> Should I create a "web...@trouch.com" address ?

* The objective/target is "Eric PTAK - trouch.com"

=> Do I need to change it to something with "WebIOPi" in it ?

Eric.

[quad...@yahoo.com]

Eric,  I just followed the links you suggested and now I see the problem that may be making things difficult for people who want to make a donation.  The problem is, everything is in French and unfortunately I don't speak French.  I can guess at what to put into most of the blanks on the page, but if the web site asks me for additional information when it processes my donation, then I won't know what to do.  Is there another donation site in English, or is there a safe way to translate the words on the page you recommended into English in real time?  Thanks for your help.  Ed  

On Friday, November 29, 2013 2:04 PM, trouch <tro...@trouch.com> wrote:

quick answer : yes, it's the good link, not a scam.

actually, you have two places to find it :

on my blog, left menu, http://trouch.com/

--

[prairietech]

Ed,  I use Chrome and it automatically translates the French page to English.

[trouch]

Seriously ? Paypal does not adapt page content to country/language ?

I always guessed it did, and I actually cannot set the language for the donate.

I just changed the language of the account to English, may it change something ?

[DavidVT]

Thank you for this project.

As someone who has been into computers and some kind of coding as a hobby since my first vic20 some years ago...., it was wonderful to find the raspberry pi community. Webiopi is an important part of that community!

Despite my comfort level with computers, it has not been a career and my skills are a bit rusty now. Webiopi has helped me get deeper into Linux, Python, etc.

My outdoor wood boiler is now on the Internet and I can monitor it from work (or from my bed on a cold morning). It is not perfect yet but the activity to create it is so much more rewarding than many nights of mind numbing television.

How to encourage more development? As an example for me, At this point I am curious only how to make my I2C 1wire master device get registered properly without having to do it manually on each reboot. Is this something I can learn myself and master so to contribute to the project, or is it only in the hands of trouch?

Is financial the only way to support the project or is there a clear path to help,with devices, examples, community dialog (good now), etc.

FYI: From my iPad using Chrome, I reach a payPal page in French with only a choice to donate Euros. I would prefer a more generic with USD as an option.

Keep up the good work!! (Please)

[quad...@yahoo.com]

I had the same problem you did with the PayPal donation page in French.  I hate PayPal, it always requires me to answer many complicated questions and I could not have done that in French. But, Eric gave us a useful tip when he said Google Chrome has a built-in language translator.  This is not obvious, because the translate option is not a Chrome default, it has to be activated and it's buried in the advanced Chrome settings.  The language to be translated has to be specified, but once you get it set up, the translation from French to English is excellent.  I see that you use Chrome so this solution should work for you the way it did for me.  If the Euro issue bothers you, there are plenty of Euro-to-Dollar converters on the web so you know how much you're donating.  For example, twenty Euros works out to less than thirty US dollars.  Eric has given us WebIOPi and Cambot and after all this time we have supported him with less than three hundred bucks in total donations and most of that was donated by one person.  We have all benefited from Eric's work, so lets all do something for Eric.  If each of us only donates a small amount, then it will add up and make a nice Christmas present to show Eric how much we appreciate his work.   I made my donation yesterday, it was small but at least it was something, so how about the rest of you guys.   Incidentally, I have no connection with Eric other than benefiting from his work and my comments about donations probably embarrass him, but somebody needs to speak up for him.   

--
You received this message because you are subscribed to the Google Groups "WebIOPi" group.

To unsubscribe from this group and stop receiving emails from it, send an email to webiopi+unsub...@googlegroups.com.

[trouch]

Thanks for your feedback and support guys.

I'm very honored to receive donation, whatever the amount is. Even 1€ is good.

Your support messages are also really appreciated.

I tried to change the default country of the donate button, but I cannot manage language.

Paypal is supposed to display using the user language.

@David you should look on existing drivers sources.

There is few helper to automatically load modules.

But if you need to register devices, you still have to do it manually.

Nevertheless, you can write a script that will be loaded at linux startup.

@Ed I do not blame people don't donating, I'm happy to provide WebIOPi.

I just would like to keep it going further. I need time and certainly motivation.

Thanks you

Eric / trouch.

[quad...@yahoo.com]

Eric, PayPal does not translate for us in the US, maybe it does in Europe, but not here. I have been using your software for a long time and wanted to make a donation, but like many people here I couldn't get past the language problem.  Also, I didn't know  

--
You received this message because you are subscribed to the Google Groups "WebIOPi" group.

To unsubscribe from this group and stop receiving emails from it, send an email to webiopi+u...@googlegroups.com.

[quad...@yahoo.com]

Message Continued:  Also, I didn't know until yesterday that Chrome can translate PayPal web pages, because it doesn't come set up that way here. PayPal wanted extra information from me to complete the transaction and I didn't know what PayPal was asking for in French, so I was not able to donate until Chrome solved the language problem.  Thanks for your tip about Chrome containing a translator.  You don't need to change anything, because there is no reason why people in the US who want to make a donation can't use Chrome to translate your existing PayPal web page.  

[DavidVT]

Agreed on the current paypal config as being adequate. The currency selection only showing Euros takes a few moments to bring up another tab to google to learn the exchange rate.
There is a chance Eric might catch more donations with more language and currency selections but it works as is!

[Andreas Riegg]

Hello all,

Besides funding, let's also talk about tech.

Sorry for the long post, but I think it is better to have all input in one place. And - this is NOT a wish-list, its just a detailed analysis what could make sense or which options exist. Its completely up to Eric and his funding what can be realized or not.

Hardware Layer

 

Concerning the base hardware connection functionaltiy, WebIOPI does already do a job that no other comparable toolset for Raspi provides (afaik). There are many libraries or solutions to control various chips or hardware extensions, but none of them controls so much I2C and SPI chips in one integrated solution and none of them exposes them to a HTTP REST API that can be used local via localhost as well as remote across the network.

Two major things are missing: Easy support for 1-wire devices and the edge detection thing.

There is a kind of solution for some 1-wire chips as proposed in some other posts, but this will introduce additional dependencies and even open source kernel drivers don't exist for all kinds of 1-wire chips (like some digital IO chips afaik). Maybe one way is to accept some dependency on OWFS and try to write a hardware driver that integrates with that as close as possible - and the whole thing being optional so that users that don't need 1-wire chips don't have the burden to get OWFS installed on their Raspis.

The edge detection thing seems more important. Primarily this can be used to detect level changes on digital ports without software polling. But more important will be the possibility to react to interrupts that many chips can generate in specific situations like AD conversion ready or some hardware-monitored edge detections of digital IO chips. Feeding back those events to clients has two stages: First step is back into the Python server, I hope this can be done with a native C routine that triggers some Python server method so that there is a chance to react to the detected edge within the server more easy. The second step is more complicated, this is now across the network layer to any headless or GUI-based client. This is not possible with the HTTP API that WebIOPi currently uses directly. The only idea I have to get this in a "light" version could be to enhance the /* status response with one or more JSON slots that could indicate that an edge detection has been registered by the server, maybe including an ID that gives a name. This way polling by clients would be only necessary for the overall status and not for individual values or ports.

Client libraries could look for those indicators and re-produce the detection events on client level. From my experience polling intervals at 10 times a second for /* don't eat up too much CPU from the Raspi so reaction times around 100ms are possible without hassle. However, if some chips are present that have a long conversion time and thus delay the /* state resonse may be a problem. So, another solution would be to have a separate edge status detection status call like .../event/* or so. Nothing that would be patent-pending, but it will work. More thoughts on this below on the protocol topics.

Minor potential enhancements on hardware layer include a broadening of the hardware drivers functionality. This is some work to do, but its more volume-like work than rocket science and can evolve over time on a volunteer base as soon as the hardware driver class library is stable and a tutorial "How to develop a WebIOPi-driver" has been made available. I don't know if this would be possible, but as we are using Python at the server level it could also be possible to decouple hardware drivers a bit from each other. If the different hardware drivers were "self-contained" or "self-registering" in some way, this could simplify hardware driver development a lot. By providing one file (or more files in a subdirectory) a new driver could be registered and added at runtime or startup time without changing the driver class hierarchy or modifying one of the existing driver classes. Just some kind of mechanism usually used by plugins. It could inherit all the standard functionality and just add the new things. In such a constellation WebIOPi would have a standard set of drivers maintained by Eric and optional other ones maintained by others. It could be also possible to enrich existing drivers for chips and maybe integrate that over time into "kernel" WebIOPi.

Protocol Layer

On protocols for IoT (Internet of Things) level, I see four interesting families of stacks (all based on IP stack)

• Simple HTTP- and JSON-based REST APIs like WebIOPi does today. Call it the must-have bread-and-butter solution.
  
• Extended HTTP-Family API based on WebSockets. Gives additional possibility to deliver direct callback events to clients (e.g. detected edges). Call it the like-to-have bread-and-butter-and-marmelade solution. Discussion will be to mix this with the standard HTTP API or not (what I would prefer)
  
• Low bandwidth COAP-based solutions like WebIOPi does today as tech preview. Originating in the academic world, innovative but may take some years to evolve, so its more a wait-and-see kind of thing.
  
• Industrial grade high-end while still lightwheight MQTT protocol family. Originating from IBM but somewhat open and standardized now. Call it the enterprise solution. Interestingly, Facebook Messenger also uses this protocol. So this could be a "why not have it if it is not too much effort" thing. But for limited developer resources, it may stay optional. However, this could be an interesting item for Eric's employer (to give him some spare time) as this IoT protocol has the potential to play an important role when doing IoT projects with solutions from big IT players like SAP, CISCO, IBM, ORACLE, etc.

There are also WebServices/SOAP and the UPNP/DLNA protocols, but they all require XML parsing, while still doable with Python, it may be too much effort, so I would stay off them for now.

A very important question is the layering of the network connectivity of the WebIOPi. Currently all protocols (HTTP and COAP) are fully integrated, maybe it would be also an idea to make this thing pluggable in some way like the hardware drivers, especially when another HTTP server would be needed because of the WebSockets stuff. Direct feeding back of events looks to be only possible with WebSockets (thats why it is so important), COAP and MQTT look to be more pub/sub model oriented which may be ok in many usage scenarios. So pluggable selections of the network protocol family could be an option.

Client Layer

On client level, we have two categories of clients: Headless and GUI-based. With the exception of JScript it may be a good idea to provide some client libraries that do some kind of basic abstraction and object serialisation stuff. But not much more as the remainder especially of GUI-Clients will be very dependend on specific GUI frameworks and there are a lot of them. However, if the hardware layer gets more flexible and pluggable it may be not so easy to have all the hardware abstractions present 1:1 in the client libraries dynamically.

And, it looks like that we will get slightly different flavors even when using the same language like Java when it comes to Network classes,  Encryption and Auhentication (e.g. Android 4.x vs. Android 2.x vs. Plain Java vs- ...).  For Jscript, a complete library will be necesary so that folks that don't code their own clients (presumably most of the users) have a standard possibility to access WebIOPi server via browser and do some easier GUI customizations on HTML (4, 5?) level. Jscript support of COAP and MQTT won't be needed, but WebSockets should be possible for event responsiveness which may introduce new Jscript library dependencies.

In the mid term I see evolving tools that will allow GUI-based generation of user interfaces consuming and controlling services like REST-APIs with JSON payloads. Will take some time, but it will not be worth the effort to invest much in GUI-Tools for WebIOPi, I agree very much with Eric here in focusing most efforts on the server side. Even for WebSockets some libraries exist already to do the socket connection and object serialization stuff.

Runtime Platform

It is a very compelling idea to bring WebIOPi also to the Beagle Bone Platform as Eric mentioned already in his blog. Depending on the Beagle Distro used, the network stuff should not be a problem. Probably the most critical stuff will be the native C interfaces and the needed kernel hardware modules and to get the full hardware driver library working. However, if also a (serial control communication) hardware driver for Arduino (e.g. the brand new Gertduino) could be made available, then a full range of hardware platforms from Arduino over Raspi up to Beagle would be usable by WebIOPi depending on budget and performance requirements. Just fantastic.

More details/ideas for the various layers exist in my head, but I think this is enough for this post for now. Lets see what other ideas exist.

 

Andreas

[trouch]

Thanks for your feedback Andreas, I agree to almost all things. Few things was already in my minds also.

Hardware

1-Wire is a problem by itself. I already started to work on it next 0.6 release, but I think I will not be able to provide a complete set without few dependencies. But OWFS is not desired.

Edge-detection / Interrupts is an important point and real miss.

Actually, Edge-detection still uses a software polling loop...

Interrupts is more dependent to the linux GPIO drivers, so I may need to rewrite the whole webiopi GPIO driver to use the linux filesystem and (e)poll functions instead of the SoC registers.

About webiopi devices abstraction layer, I think I already done a good job. But it's quite hard to handle a complex board with multiple devices. This is actually more REST binding related. Then a good documentation should definitely help so people can write drivers by themselves.

Protocols

I will stick to a REST API over HTTP and CoAP, but it needs to be more consistent and use best-practices.

Accessing the root should return everything in JSON for instance. Then sub path returns sub elements...

WebSocket will be a requirement to use Edge-detection/Interrupts on the HTTP side.

There is mechanisms like PubSub in CoAP.

MQTT is far in mind. I may rather implement WAMP before.

Moreover, I'd like to go to asynchronous/non-blocking handling of HTTP requests.

All of this has a strong consequences of the server design, and current 0 dependency.

The current design allow to be compatible with both Python 2 and 3, and allow an easy wrapping of lower layers with a common abstraction.

I'd like to continue this way, but it will take time to implement at least WebSocket.

By using existing libraries, I will need to writes some glues. And I'm not sure I'll be able to keep compatibility with both Python version.

Clients

With existing Java, Python, and Javascript, we already have a set of client to cover many needs. It just need to be improved, maybe with some asynchronous design. I also already thought about self-generated clients...

For other people REST API is open to write new clients.

Runtime

I bought the BeagleBoneBlack on release day (thanks to donators!), started it, seen it work and replaced it in the box.

But I still want to port WebIOPi on it. As you say, I just need to see how to handle GPIO and buses.

For everything else, it's a basic angstrom linux with python.

Conclusion

Finally, there is 2 big topics (interrupts and websockets) than can be regrouped into a single "real-time" topic.

For the others subjects, this is more about consistency and documentation I think.

But I may need to break some URI pattern and change some features (not removing them).

--

[matt whitehouse]

I was thinking you could add support for the camera module, like image processing for robots and such.

[trouch]

I'm not sure it make sense to add support for the camera module.

If it happen, it will be only a wrapper to launch programs.

But it will be hard to share the same server socket for both webiopi and the video streaming.

Nevertheless, I plan to buy one module to see what can be done.

On Tue, Dec 3, 2013 at 1:25 AM, matt whitehouse <whiteh...@gmail.com> wrote:

I was thinking you could add support for the camera module, like image processing for robots and such.

[prairietech]

Toshi,

Would it be possible for you to list your index.html file for your Capture.JPG from your posting above? 

You should get a special award for a masterpiece like that.

[Maciek Wąchalski]

I would be nice to have scheduler build in Webiopi, so we could define timer event times and add/edit timer events via http. 

[trouch]

task scheduling is planned is the ROADMAP

https://code.google.com/p/webiopi/issues/detail?id=19

On Wed, Dec 4, 2013 at 9:06 AM, Maciek Wąchalski <maciej.w...@gmail.com> wrote:

I would be nice to have scheduler build in Webiopi, so we could define timer event times and add/edit timer events via http. 

[Andreas Riegg]

Hi,

 

two simple questions:

 

What would we loose when giving up Python 2.x compatibility? (And  - as long as WebIOPi has zero dependencies with its own C libraries and HTTP sever this would not matter at all.)

 

Could CherryPy be a viable alternative for the whole HTTP-Server stuff. It looks like running on Python 3 as well and has some good helpers for handling Authentication, Security and REST API's.

 

Andreas

[trouch]

Compatibility with both python version is not a feature problem,

The problem is about exception and primitive data types handling on byte, bytearray, string literrals, unicode....

Behavior and existing data type differ from Python 2 to Python 3.

http://python3porting.com/noconv.html

There is actually mainly two possibles web framework.

CherryPy, as you mentioned and already planned in the bugtracker

But I need to look deeper in cherrypy because of the REST API and current webiopi design.

CherryPy abstraction level may be to high or incompatible with my needs. I may need to rewrite the whole core, not just a glue.

Twisted may better suit my needs and current design, but it's not compatible with python 3.

Eric.

--

[Andreas Riegg]

Eric,

 

just came occasinally across this document and it may be helpful for you when thinking about (possible) changes to the REST API. And, I think WebIOPi does already a very good job after a first look at the document.

 

You will find much more potentially interesting information about API Economy on their website.

 

Andreas

[trouch]

This is a nice resume of common best practices and REST meaning.

It's nice to see few versions and error handling tips.

I think I'm already aware of most concept enounced, but I will take a deeper look.

The most out-of-best practices used is WeIOPi is that I only allow values directly in the URI.

Eric.

--

[Toshi Bass]

Hi Eric

I just got email from you regarding     Reminder : WebIOPi survey    it implies that you have sent an email prior to this, for sure that is not the case, this is the first email I received from you regarding a survey, second point I assume in the survey when rating WebIOPi  that like, 1 is poor and 5 excellent, not the other way around !

Toshi

[Trouch]

You were in the list of the first mail toshi !

It was sent on december 1st.

I suppose it fall into your spam box.

Can you check it please ?

And yes, 1 is very bad, 5 is excellent. 

--

[Toshi Bass]

Eric

I checked again including spam folder etc, I definitely didn't get any email from you prior to today only the usual forum posts, if your not getting many replies perhaps there was a problem with your first emails !  

Toshi

[Robert More]

I received the same email Toshi and had not received a first.  Filed it out anyway.

Eric, it is good to see you back onboard!!!

[trouch]

Mmm, very weird and sad... may be gmail dont like mails with hundreds recipients.

you were both included in the first mail, entitled "WebIOPi needs your help"

The first mail included a longer story, you can also found it on my blog

http://trouch.com/2013/12/01/webiopi-needs-your-help/

I may post it also on the group to ensure more responses.

--

[Herbert Schönleutner]

I've received both mails.  :-)

[Robert More]

Found original in spam box

[Matthew Budraitis]

Thank you for the new tutorials you posted.  I knew this would make my project easier, but I was struggling getting started.  The new tutorials got me over the hump.

On Tuesday, November 26, 2013 4:00:51 PM UTC-6, trouch wrote:

Dear fans,

WebIOPi is alive for more than a year now, and last release was 8 month ago.

It has been used around 150000 times by 50000 users, I never expected such a success !

I really apologize for being away from this board all this time.

I would like to thanks the most active users on the webiopi group for the help they provided :

1. me (285 posts)
   
2. Toshi B. (108)
   
3. Andreas R. (73)
   
4. Robert M. (49)
   

I also would like to thank people who gracefully made donations to me since the 0.6 release.

The total received is exactly 198.40€ with 10 donators, including a single 100€ donation on last week.

Not that bad, I really appreciate every single donation, but it's not enough to push the gear up.

I'm still thinking to resume the WebIOPi development, but I'm not sure where to go.

The main objective is to provide a multi platform solution, compatible at least with Raspberry Pi and Beagle Bone.

There is also an old roadmap with many features : https://code.google.com/p/webiopi/wiki/ROADMAP

As I'm not good at UI designing, I may refocus on the Server design, features and APIs.

I'm also facing few issues related to protocols handling and the no-library current design.

This topic intend to group users requests to watch interests and plan the webiopi next steps.

Feel free to tell how do you use WebIOPi, difficulties encountered and missing features.

If you wanna help and already looked in the sources, you can contact me directly on my mail.

Depending on feedback, I will then decide to resume or not and what to do.

Eric / trouch.

[Oliver Horn]

Eric,

the new doc seems to work great..

just found webiopi, then...

- installed and immediately had a clear view about gpio states
- changed a pin to "in" and got visulized reactions on wiring 3.3v to the desired pin...
- then installed 2 18b20 sensors to 1wire as described elsewhere, loaded modules for 1wire support, added the 2 sensors at the config file, and here we are... could see the temperatures in the standard ui devices monitor.

Great!

All that without coding a single so far,
no frustration, not a minute -> "Noobs proof"

Will step forward with:
- donating at least some small amount (I payed for the sensors, breadboard, resistors, cable, the pi, several books, ... so: should also pay for this wonderful piece of software!)
- helping with a beginners' guide to sample projects, if you're interested.
- adding relays (actors) for some switching
- adding serial communication to my heating system (working with gpioserial, bashscripts and my smartphone enabled ui via jQueryMobile today)
- do some ui work (combine webIOpi and jQuery, jQuery Mobile and maybe D3 for graphs later on.
- propagate webIOpi on several forums & websites I use.

[Eric PTAK]

Thanks for your comments guys !

Kinds messages and direct support thought donation (even small amounts) help a lot ant motivate me !

[sanchit khandelwal]

Webiopi is certainly very helpful and powerful tool for people like me who are good with technology but are not very much into programming themselves. I'd like to see a detailed guide about how to use Webiopi detailing each and every step that needs to be taken for creating different utilities, written keeping people like me in mind who would like to use this tool but are unable to explore full capabilities of it because of the lack of programming knowledge.

Thanks 

[Eric PTAK]

did you seen new tutorials ?

they are more detailed and clearer than old documentation

a book is also planned with even more details

--

[ALJ]

Just donated, keep up the great work!

[Eric PTAK]

A thanks you acknowledgement has been sent on your paypal address ;)

--