--
--
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)
Hello all,
Besides funding, let's also talk about tech.
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)
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.
--
I was thinking you could add support for the camera module, like image processing for robots and such.
Toshi,
I would be nice to have scheduler build in Webiopi, so we could define timer event times and add/edit timer events via http.
--
--
Hi Eric
--
--
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 :
- me (285 posts)
- Toshi B. (108)
- Andreas R. (73)
- 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/ROADMAPAs 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.
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.
--
--