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 you 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++...

Ok, let me show you what I have in mind.

Virtual Device

This will be the central feature of pKNyX, allowing user to create virtual devices which mimics real KNX devices. They will follow the same architecture, like having Datapoints (aka as Communication Objects), which have to be linked to Group Address to communicate.

Here is a very simple example of what I have in mind: creating a virtual weather station, which uses informations from a non-KNX real weather-station, or even from a web site, like Weather Underground or so:

from pknyx.api import Device, ETS

# Weather station class definition
class WeatherStation(Device):

    # Datapoints (= Communication objects) definition
    DP_01 = dict(name="temperature", dptId="9.001", flags="CRT", priority="low", initValue=0.)
    DP_02 = dict(name="humidity", dptId="9.007", flags="CRT", priority="low", initValue=0.)
    DP_03 = dict(name="wind_speed", dptId="9.005", flags="CRT", priority="low", initValue=0.)
    DP_04 = dict(name="wind_alarm", dptId="1.005", flags="CRT", priority="high", initValue=""No alarm")
    DP_05 = dict(name="wind_speed_limit", dptId="9.005", flags="CWTU", priority="low", initValue=15.)
    DP_06 = dict(name="wind_alarm_enable", dptId="1.003", flags="CWTU", priority="low", initValue="Disable")

# Instanciation of the weather station device object
station = WeatherStation(name="weather_station", desc="My simple weather station example", address="1.2.3")

# Linking weather station Datapoints to Group Address
ETS.link(device=station, dp="temperature", gad="1/1/1")
ETS.link(device=station, dp="humidity", gad="1/1/2")
ETS.link(device=station, dp="wind_speed", gad="1/1/3")
ETS.link(device=station, dp="wind_alarm", gad="1/1/4")
ETS.link(device=station, dp="wind_speed_limit", gad="1/1/5")
ETS.link(device=station, dp="wind_alarm_enable", gad="1/1/6")

Note: I skipped some part of the code, like the device registration and other stuff like that

That's it! As you can see, concepts used here are not new... This device can be then used from any other real device of your installation, through GADs 1/1/1 to 1/1/6. All you have to do, is to link the Communication Objects of your real devices to these GADs, using the ETS application. For example, the DP Nr 4 will send the "Alarm" value over the bus when the wind speed will reach the value stored in DP Nr 5, but only if the value of the DP Nr 6 as been set to "Enable". By linking this alram object to the alarm entry of you sun blinds, you can save them from destruction!

Ok, but how the device knows the current wind speed? Well, it does not... yet! Let's see how it can be done:

from pknyx.api import Device, ETS

# Weather station class definition
class WeatherStation(Device):

    # Datapoints (= Communication objects) definition
    DP_01 = dict(name="temperature", dptId="9.001", flags="CRT", priority="low", initValue=0.)
    DP_02 = dict(name="humidity", dptId="9.007", flags="CRT", priority="low", initValue=0.)
    DP_03 = dict(name="wind_speed", dptId="9.005", flags="CRT", priority="low", initValue=0.)
    DP_04 = dict(name="wind_alarm", dptId="1.005", flags="CRT", priority="high", initValue=""No alarm")
    DP_05 = dict(name="wind_speed_limit", dptId="9.005", flags="CWTU", priority="low", initValue=15.)
    DP_06 = dict(name="wind_alarm_enable", dptId="1.003", flags="CWTU", priority="low", initValue="Disable")

    @Device.schedule.every(minutes=5)
    def readWindSpeed(self):

        # How we retreive the speed is out of the scope of this proposal
        # speed = xxx

        # Now, write the new speed value to the Datapoint
        self.dp["wind_speed"].value = speed

        # Check alarm speed
        if speed >= self.dp["wind_speed_limit"].value and self.dp["wind_alarm_enable"].value == "Enable":
            self.dp["wind_alarm"].value = "Alarm"

# Instanciation of the weather station device object
station = WeatherStation(name="weather_station", desc="My simple weather station example", address="1.2.3")

# Linking weather station Datapoints to Group Address
ETS.link(device=station, dp="temperature", gad="1/1/1")
ETS.link(device=station, dp="humidity", gad="1/1/2")
ETS.link(device=station, dp="wind_speed", gad="1/1/3")
ETS.link(device=station, dp="wind_alarm", gad="1/1/4")
ETS.link(device=station, dp="wind_speed_limit", gad="1/1/5")
ETS.link(device=station, dp="wind_alarm_enable", gad="1/1/6")

All we do, here, is adding a method periodically called by the framework (every 5 minutes in the above example). In this method, we retreive the wind speed (not explained here), and give the value to the Datapoint Nr 3. If the value has changed from the previous call, the Datapoint will automagically transmit it to the bus (according to the flags, of course).

We also check if the speed has reached the speed limit; if so, we change the corresponding Datapoint value, which wil, in turn, send the value on the bus if needed (a special value of the flag, like in linknx, can force the value to be sent, even if it does not change).

That's it for now. This is only a draft version; final implementation may change, according to feedback/suggestions I will get. But the core is all there. Again, the goal of the framework is to provide very high level tools to build complete and powerfull applications and KNX extensions.

Other ideas