Proposal

This page is more or less a sandbox where I put my ideas. Feel free to comment.

Main line

pKNyX is not a ready-to-use application: it is a framework. This means that it is up-to-you to write the application which fits your needs.

For that, you will need to know Python, a powerfull , high level, object oriented, scripting language. Don't be afraid: Python is really easy to learn. It is now very popular, and used in many free and commercial applications to extend their capabilities. It is now even teached at school, to young people (~15 years old)! There are hundreds documentations, tutorials and examples on the web, and a huge community. Learning Python is really not a waste of time, and will help you to do many other tasks than simply building your KNX application!

pKNyX will provide powerfull tools so you will only focus on your problem, and not on language subtilities, like it can be the case with other languages, like C, C++...

Virtual devices

See the Tutorial.

Caching and persistence

pKNyX will have to implement a cache mode to avoid too much load on the bus.

By persistence, I mean the ability to store usefull informations (like Datapoint-s changes) to a database.

linknx compatibility mode

As I still want to use knxweb, I also plan to develop a special device-like object to mimic linknx behaviour. All it has to do is to provide the basic xml services used by clients, to display bus status and send orders. Other features, like advanced configuration, rules and so, will be omitted.

Again, we can use the same Functional Block paradigm. The framework will may have to provide another custom class for that purpose, but it will be used the same way. It will just add specific features, and the internal structure to act as a linknx-like server.

Not planned anymore

Specific server mode

The purpose of this is to provide the model part of an automatic web page generation mechanism. The idea is to provide a simple list of usefull informations/settings, as widgets, which can be used from smartphones (simples buttons and displays). The client gets a config from the server, and build the GUI accordingly. Then, client and server communicate to maintain their respective state, depending on KNX and user actyons.

Client side is developed using ​qooxdoo. Communication is based on REST.

The client is almost done; need to implement the server part.

Unsorted ideas

• create managers to get status of all running applications