Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
using pKNyX to access real bus devices
#1
Hi

Today I posted the following question to Frédéric concerning his pKNyX framework and he asked me to post it here too so interested people could join the discussion.

"Could pKNyX also be used to access already existing devices on a bus? Like a proxy-device that forwards communication to a real device through bus communication.
I'm trying to expose the Objects on the bus as web services so I would need Objects that I can extend with serialization functions, no matter if they are virtual devices living in python only or real devices hooked up to the bus."

He got back to me saying that pKNyX can't do that right now but that ist was on the roadmap for the pKNyX development. I want to elaborate a bit more on my project so everyone gets a better understanding of what I'm trying to do.

The goal is to have a REST webservice provider that enables access to the KNX bus. This provider shall be build in layers so that there are multiple abstractions for the devices and group objects on the bus.
For Example say you want to switch on a light. You might have a REST webservice under the URI http://knx.example.com/groups/1/1/21 that enables you to read and write the group object with the bus address 1/1/21. So the URI ../groups is the basic service to access this group object.
The same bus operation might be acessible through an abstraction layer, say something like http://knx.example.com/headquarters/buil...ling_light. Through this abstraction I can offer someone without knowlege of the bus internal structure the possibility to switch this light on.
So far I could solve this without pKNyX. But there are bus operations that can not be directly mapped to REST webservices because a webservice is a request/response communication. Sometimes I am interested in bus messages that are sent spontaneously like say a weather station that sends the current temperature every 15 minutes. I could always keep polling for the cached value but thats not a very good practice. pKNyX can help me solve this problem better.
I could use a REST webservice to POST a new virtual device to the bus that acts as a data sink and records the temperatures for me. All I would have to do is connect periodically and collect the stored values. Once I don't need any more temperature values, I can just use HTTP DELETE to remove the virtual device again.

So far the idea for the project. For this to work, I would need to have way to access both virtual and real devices through the framework. Currently I'm working my way through the eibd documentation and try building a more pythonic client module for eibd because the one included in the eibd-clients package is just translated C-code and for a python programmer it's almost unusable.
Répondre
#2
Thanks for the public post!

Ok, this is really an interesting idea, and I think it exaclty matches what I planned to do, at least for the second part (abstraction access). One of my goal is to be able to automatically build a web interface sithout the need to configure anything on the client side: all informations have to be provided by the server.

At a global level, the server should provide a list of all devices (or, more exactly, all sub-parts of devices, which are more or less Group Objects, but not exactly) available; then, each 'device' should provide all usefull informations about itself: type (light, heater...), location (building, room...), DPT (1.xxx, 9.001...) and so on.

Then, accessing information the way you describe seems logical; I have to admit that I didn't think about it before, as I'm not a web developer, but I like this idea.

One idea I have is to add some new objects in Function Block, at the same level of Group Object, dedicated to the above tasks. I don't know yet if it could solve all our needs, but as I said, I would like to keep the number of paradigms as low as possible, as python does.

Ok, this is for virtual devices. What about real devices? I would like to avoid the need to describe again the entire installation (real devices), as we do with linknx, but I don't see any way to avoid that. If we do so, how? I think virtual devices can act as relay to/from real devices as they are implemented right now. But I like the idea of having Proxies... Don't know yet if this should be some additionnal objects (a new paradigm is not the best choice), or if it can be implemented as specialization of existing objects... I'm open to any idea.

Last, I just wanted to say that I plan to use Ext JS 4 for the client app I have in mind; this framework seems very powerfull and looks nice.
Frédéric

http://pknyx.gbiloba.org (actuellement cassé, mais bientôt de retour !)
Répondre
#3
(03/03/2014, 23:00:06)fma38 a écrit : all informations have to be provided by the server.
Thats exactly what I mean. Since REST tyipically doesn't use any service description like SOAP does with WSDL the resources need to be as self-descriptive as possible.

(03/03/2014, 23:00:06)fma38 a écrit : I would like to avoid the need to describe again the entire installation (real devices), as we do with linknx, but I don't see any way to avoid that.
I've been looking into the *.knxproj files that the ETS application exports. The Calimero suite comes with an XSLT that transforms the XML files to the format Calimero can use as config file for the exisiting group addresses. I plan to leverage this to extract as much information from ETS about the devices as possible. The other options is to use management communication. Some of the device configuration (like the group adress table) can be read from the device by reading datapoints that are exposed as interface objects.

(03/03/2014, 23:00:06)fma38 a écrit : Last, I just wanted to say that I plan to use Ext JS 4 for the client app I have in mind; this framework seems very powerfull and looks nice.
I haven't looked into options for the client side yet. I'll probably just implement a proof of concept with a simple web framework like Flask.
Répondre
#4
(04/03/2014, 06:39:30)KevinB a écrit : The other options is to use management communication. Some of the device configuration (like the group adress table) can be read from the device by reading datapoints that are exposed as interface objects.

Any idea how to do that? I guess this would require to improve the KNX Stack implementation...
Frédéric

http://pknyx.gbiloba.org (actuellement cassé, mais bientôt de retour !)
Répondre
#5
It's possible through cEMI frames. Im not clear on the details yet but I'm looking into that.
Répondre
#6
Just a heads up. It looks as my project will remain a theoretical one. The KNX standard is so complicated I just don't have enough time left to attempt an implementation.

I will carry the virtual device concept into my research paper and also include a link to the pKNyX website. Maybe my professor can find someone else to do the implementation.

Concerning the management communication I'm almost positive that one could use the Transport-Layer functions of eibd to send and receive cEMI frames. I posted a question on how to use cEMI frames to the eibd mailing list but got no answer.
Répondre
#7
The other options is to use management communication. Some of the device configuration (like the group adress table) can be read from the device by reading datapoints that are exposed as interface objects.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)