| Forum: System Design |
 |
13. Aug 2008, 20:11 CET | Link |
Ok I as I mentioned I have received the KNX spec and I have uploaded it to the open-remote site. If you want access to the set of documents let us know. I am playing with it and reading as my fancy dictates, I have got about 300 pages done. I got to say it feels 10,000 pages long and it could fit, at least from the application standpoint into 50 pages.
They spend 40 pages specifying a clock. It has basically 2 calls: get/setTime, get/setDate. In most specifications this would be a 2 lines specs, But no, it is 40 pages of pompous stuff.
Then the lighting application. It does define sceness but the thing is 100 pages long to describe on/off, status, dim(value) and scene commands/learn. The thing has a state diagram that is so complicated it made the EJB spec (for those in the know) look like child's play. So I got to say, I AM COMPLETELY TURNED OFF (no pun intended).
Sure, the spec is complete, it has everything, but then there are basic grammar mistakes in it, Sentences that don't make sense (even if I try hard) and the like that smell like employees writing 100 pages to justify a job when they could write 2 pages and be done. It doesn't make a good impression on me.
In short what I am saying is that the object model is over-kill. It reminded me of J2EE, in its un-necessary complexity...
On the big plus is of course the standard telegram. That on-the-wire format, will be interesting in interworking
, as they call it, with KNX devices, but putting our internal object model on the KNX OO model would be a mistake. We need a Java API internally and we call it a day. I guess,
I will stick my neck out and say that we can code a decent OO model for the 1000 pages of application crap in KNX in about a week. Specification be damned. It will be enough to command a KNX system as long as we get the telegram right.
Lastly, have folks here on the list implemented KNX? feedback appreciated...
Back from vacation, I only read the intro so far.
So I guess we should seriously think about integrating Calimero and just it from our internal model. And spend more time on this model than reimplementing such a thing.
I'm going to take another look at xAP for the internal addressing and message model as the base. There are issues that I'd like to see fixed (christian pointed some out, check the knowledge-base) but basically it comes down to having a defined string serialization format for addressing and messages that is extensible enough to support at least some number (unknown to me at this time) of existing control protocols and has some proven track record of being able to integrate them. Unless you tell me there's a better solution there in the KNX land for this (telegram internally?). BTW, where do you keep the specs?
So the one thing this brings is a defined and proven serialization format which allows us to cut to controller down to as small components as we want, and recycle.
Juha Lindfors, OpenRemote
Join OpenRemote Chat
FWIW, I liked xPL better than xAP. I'll contact you about the spec.
Part of where I am ending up at is that
1/ The object model is kind of trivial. Modeling a house floor plan takes about 20 seconds. Understand the API to a light system takes about 5 seconds (on/off/dim). Sure sure, scenes, learning, blah blah blah.
2/ The on-the-wire message is a reference implementation issue and not one that concerns us overly from a internal modeling standpoint. In fact, whatever is implemented by insteon/KNX/xPL is again, just a on the wire format that is understood or not by physical devices. But in no way is the fact that it is encoded over 3 frames of 8 bits a relevant bit of information from a model/programming standpoint.
Don't me wrong, these issues are at the heart of physical device interoperability and thus most relevant to the field of HA and we will need to offer support to these. But in no case are they relevant to object models.... there is very little in the way of object model, I have been barking up the wrong tree.
I'm not thinking object models at all at the moment. Only about the internal serialization format for the routing prototype I'm testing in the controller. The structure of the message with addresses and commands. This would be the common language inside the controller or between controllers.
I like xPL or something like xPL (or a super-set of it) because:
So initially going to try with something and see how it goes.
Juha Lindfors, OpenRemote
Join OpenRemote Chat
That is because Inteworking either works or does not work. It is a binary matter: yes, or no. There is nothing like or . If one detail does not fit, between applications of two different manfacturers, then you may as well forget about it. The specification of the System Clock specifies a master and slave - in case you hadn't seen. Moreover, the detailed specification of the Datapoints is only relevant for engineers and programmers developing and testing the product. If you cut this, the paper is reduced to about 10 pages. By the way, nobody has ever died of reading too much. But people get heart problems when things don't work because of lack of information.
NOTE The RS232 specifications take about 30 pages. The basic USB specifications take about 600 pages. I mean, if you want things to work in a guaranteed way, with comfort for the end user and not cutting on functionality, ... you per definition have to conclude on a lot of things.
Please give some examples.
No. It's complete.
That's a basic misunderstanding: KNX works basically data driven, not command driven. Command-driven, it would never have the functionality without being even more complex...
Hey Stephen,
I am now a certified KNX member. I just the completed the 5 day course at Ivory Egg. I come away with a new appreciation for KNX.
KNX is not what I thought in the first place. It IS very good at what it does.
KNX is command driven btw, that is what the group addresses are for, basically subscription channels to bits coming out of sensors.
I can't find such indication. Can you please give some more precise reference?
a Group address is effectively a publish subscribe mechanism for building and home automation.
Hey, don't be so defensive, you are amongst friends here. :)