03/03/2014, 19:06:56
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.
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.