The keyboards are all very similar, it is essentially a single type of device and MIDI can only support the music protocol. The music protocol itself is very well defined, unlike the fluid ecosystem of home automation devices. But l hope that one day this problem will be solved and my washing machine will be able to play the tune on my MIDI keyboard :rofl:samgreco said:
Frustrated with home automation software
- Thread starter Deane Johnson
- Start date
wuench said:
SNMP can easily handle determining the device limits. I would assume there would be a MIB defined for a "generic" Home automation device. Looking at the sample MIB TOASTER-MIB
We can see the toasterDoneness which has a defined range (1-10) that can be queried to find the current setting. You could also have items like limitHI and state the "high" limit.
And are you saying Z-Wave or ZigBee is not over engineered?
And whether it is SNMP or HNMP (Home Network Management Protocol
) I do not care. But having 30-50 protocols is just plain dumb!I would think it would be good to define the protocol to be transport independent so the protocol coul dbe used on TCP or one-wire or any other transport.
Anyone use or work with BACnet?
-jim
We can see there could be clearly defined values that could be queried. So a query to a defined OID string could represent limitHI.
Dean Roddey
Senior Member
MIDI probably isn't a good example. Or, maybe it's a very good example, but a counter one. As I keep droning on about, there's syntax and there's semantics. A common protocol at its base deals with syntax. It defines the words and sentences used by devices to communicate. But, for it really make a difference beyond where we already are, it has to deal with semantics, i.e. what do these messages mean, and at a higher level what are the devices that are talking and how do they work and what can they do.
MIDI is a specialized protocol, for music, so it does provide some basic semantics. And that allows for basic interconnection of those specialized devices and some basic understanding of what they are trying to say to each other. The core part of the protocol, the sending of note off/on and note velocity events, has inherent semantics, so other devices can understand what is desired of them.
But, once you move beyond that, if you try to apply MIDI to other types of devices, it can be done, but those inherent semantics are no longer really valid. And certainly anyone who has gone beyond that with MIDI and had to set up some complicated MIDI CC control stuff between devices understands what I'm whining about. At that point, you are beyond the basic, inherent semantics of the protocol and it once again can get quite complicated to set up, because now you the human has to know the semantic intent of the messages and make sure that they are set up to do the right thing. That doesn't happen auto-magically.
In the automation world, an equivalent scenario would be a dedicated common protocol for, say, thermostats. It would provide inherent semantics because any automation system using that protocol would know its dealing with thermostats and the protocol would define what a thermostat is, what it can be asked to do, what information it can provide, and what states it can have and what can be asked of it in any given state. That would make it pretty easy to set up control over thermostats, though of course it would also mean that any feature that lies outside of that semantic framework would not be supportable. And, though you could probably hack it to support some other types of devices, the semantics it defines would no longer be valid and it would be no better (and probably worse) than what we already have.
A truly ubiquitous, useful common protocol would have to provide that sort of semantic framework for every single possible type of device, which would be a massive undertaking. And, it would, to be useful for the sort of folks who hang out around here, have to set a fairly high semantic bar, which would inevitably leave out a lot of hardware because it just wouldn't be able to meet the requirements (technically or financially.) If you go the other way, and set the bar low and make lots of functionality optional, then it's worse than where we are now really, since it becomes very limiting and you can't really make any assumptions about anything up front (which is the great benefit of standardization in terms of allowing you to create reusable systems or reusable bits of systems that can be assembled together.)
In reality, most protocol that are targeting the 'internet of whatevers' is likely to be the low endy version, allowing for simplistic interaction between devices without a central controller, but being of limited use for folks who are looking to create serious automation solutions. That sort of scenario would end up being much like Z-Wave is today, allowing very simple interaction between devices without any real setup requirements, and basically the simple remote control on a phone type interface without any real integration.
Any truly ubiquitous protocol that would serve the needs of the types of folks who hang out here would be an epic undertaking, both technically to define, and politically and economically to get it accepted at a wide enough level to ever get a foothold and become successful. So it's extremely unlikely to happen.
Any truly ubiquitous protocol that was of the other sort (the low endy variety), if it did become truly widespread, would just push the automation world away from what folks around here would be interested in anyway. Why would a device manufacturer bother to do the work to expose a lot of functionality that would be necessary for extensive integration when it could just provide the basic support required by this widely used protocol, and get 95% of the financial benefits, i.e. the market that's happy with a very simple remote control on an iPad type of interface with no real 'integration' of functionality? What would be the financial incentive to do that?
Anyway, I need to eat some food because my CPU is under-voltage right now and I'm losing the thread of my point. And, for that matter it's the same point I've made before anyway, so probably it was a waste of time to even say it to begin with.
MIDI is a specialized protocol, for music, so it does provide some basic semantics. And that allows for basic interconnection of those specialized devices and some basic understanding of what they are trying to say to each other. The core part of the protocol, the sending of note off/on and note velocity events, has inherent semantics, so other devices can understand what is desired of them.
But, once you move beyond that, if you try to apply MIDI to other types of devices, it can be done, but those inherent semantics are no longer really valid. And certainly anyone who has gone beyond that with MIDI and had to set up some complicated MIDI CC control stuff between devices understands what I'm whining about. At that point, you are beyond the basic, inherent semantics of the protocol and it once again can get quite complicated to set up, because now you the human has to know the semantic intent of the messages and make sure that they are set up to do the right thing. That doesn't happen auto-magically.
In the automation world, an equivalent scenario would be a dedicated common protocol for, say, thermostats. It would provide inherent semantics because any automation system using that protocol would know its dealing with thermostats and the protocol would define what a thermostat is, what it can be asked to do, what information it can provide, and what states it can have and what can be asked of it in any given state. That would make it pretty easy to set up control over thermostats, though of course it would also mean that any feature that lies outside of that semantic framework would not be supportable. And, though you could probably hack it to support some other types of devices, the semantics it defines would no longer be valid and it would be no better (and probably worse) than what we already have.
A truly ubiquitous, useful common protocol would have to provide that sort of semantic framework for every single possible type of device, which would be a massive undertaking. And, it would, to be useful for the sort of folks who hang out around here, have to set a fairly high semantic bar, which would inevitably leave out a lot of hardware because it just wouldn't be able to meet the requirements (technically or financially.) If you go the other way, and set the bar low and make lots of functionality optional, then it's worse than where we are now really, since it becomes very limiting and you can't really make any assumptions about anything up front (which is the great benefit of standardization in terms of allowing you to create reusable systems or reusable bits of systems that can be assembled together.)
In reality, most protocol that are targeting the 'internet of whatevers' is likely to be the low endy version, allowing for simplistic interaction between devices without a central controller, but being of limited use for folks who are looking to create serious automation solutions. That sort of scenario would end up being much like Z-Wave is today, allowing very simple interaction between devices without any real setup requirements, and basically the simple remote control on a phone type interface without any real integration.
Any truly ubiquitous protocol that would serve the needs of the types of folks who hang out here would be an epic undertaking, both technically to define, and politically and economically to get it accepted at a wide enough level to ever get a foothold and become successful. So it's extremely unlikely to happen.
Any truly ubiquitous protocol that was of the other sort (the low endy variety), if it did become truly widespread, would just push the automation world away from what folks around here would be interested in anyway. Why would a device manufacturer bother to do the work to expose a lot of functionality that would be necessary for extensive integration when it could just provide the basic support required by this widely used protocol, and get 95% of the financial benefits, i.e. the market that's happy with a very simple remote control on an iPad type of interface with no real 'integration' of functionality? What would be the financial incentive to do that?
Anyway, I need to eat some food because my CPU is under-voltage right now and I'm losing the thread of my point. And, for that matter it's the same point I've made before anyway, so probably it was a waste of time to even say it to begin with.
samgreco
Active Member
Apparently I am not good at making a point I did not mean that MIDI was a good technical example. I meant that it was a good cooperative example. All of the companies involved got together and agreed on one way of doing things. There were a few stragglers, but in the end they had to jump on board or not sell product.
That's all I was trying to say.
I did not mean that MIDI was a good technical example. I meant that it was a good cooperative example. All of the companies involved got together and agreed on one way of doing things. There were a few stragglers, but in the end they had to jump on board or not sell product. That's all I was trying to say.
@Dean: +1, very true.
The solution to the unified HA protocol will most likely arrive at the AI singularity event, meanwhile we'll need intelligent controllers to coordinate between various "connected" devices speaking different protocols. There is a reason we are not speaking Esperanto all around the world today.
The solution to the unified HA protocol will most likely arrive at the AI singularity event, meanwhile we'll need intelligent controllers to coordinate between various "connected" devices speaking different protocols. There is a reason we are not speaking Esperanto all around the world today.
pvrfan
Active Member
Dean's posting seems to imply that the protocol must 'understand' all of the content of everything it carries or 'rich integration' is not possible.
I don't think that's required at all.
A home automation protocol needs to be able to carry a variety of data elements back and forth between the controller and the device. A door or window sensor just needs to report "open" or "closed". A thermostat can be logically decomposed into things that can be set ("set mode: heat") and things that can be read ("current indoor humidity: 42%). During set up, the protocol can support querying device characteristics. Yes those messages have to be standardized but the universe of devices is not that big and a simple versioning system can allow for future expansion.
Then it is up to the controller how rich the integration is. If the HVAC system notifies the controller that it is about to run, and the controller reads the state of door/windows as having been open for more than 5 minutes, it can then follow the instructions the homeowner has set (text me, then my wife, but run the heat if the temp drops below a certain threshold so the pipes don't freeze, etc).
Craig
I don't think that's required at all.
A home automation protocol needs to be able to carry a variety of data elements back and forth between the controller and the device. A door or window sensor just needs to report "open" or "closed". A thermostat can be logically decomposed into things that can be set ("set mode: heat") and things that can be read ("current indoor humidity: 42%). During set up, the protocol can support querying device characteristics. Yes those messages have to be standardized but the universe of devices is not that big and a simple versioning system can allow for future expansion.
Then it is up to the controller how rich the integration is. If the HVAC system notifies the controller that it is about to run, and the controller reads the state of door/windows as having been open for more than 5 minutes, it can then follow the instructions the homeowner has set (text me, then my wife, but run the heat if the temp drops below a certain threshold so the pipes don't freeze, etc).
Craig
Dean Roddey
Senior Member
Well, no, my point was that, unless the protocol DOES define those things, it's not much of an improvement over the existing situation. People seem to complain that HA isn't going anywhere because there's no common protocol, but that's not the problem. We already can talk to anything you want to have talked to. We already know if we are talking to a door sensor or a motion sensor or a thermo.
So a common protocol that just defines the words/sentences exchanged, and maybe indicates some basic semantic info at the individual data point level, isn't going to change the situation. But someone people keep thinking it will.
The only thing that would change the situation fundamentally would be the definition of that higher level semantic content, done very well and ubiquitously implemented, so that we know not only is this a thermostat, but it's a thermostat that followed very well defined rules as to how it reacts, what states it has, what functionality it can expose, and so forth. When you have that, then you can start to get real integration going with a lot less work.
We've spent well over a year now, maybe almost two now, creating such semantic abstractions for CQC and standardizing drivers to implement them. It's been a huge boon for simplifying system setup. But, it has all of the issues I mentioned above. No hardware manufacturer is going to specially implement some basic level of functionality required to meet our requirements, and those requirements cannot be absolutely bottom of the barrel and completely open ended or they become a standard only in name, not in fact (which is often the case.) So a lot of hardware cannot realistically meet those requirements and cannot be supported. And some that have the functionality have such ratty protocols that they are difficult to really support in a clean way, and it requires heroic programming to fake our high level semantics in the driver itself and try to force the device to follow along.
If you don't have a good, at least mid-level definition of all devices, what they can do, what states they can be in, what they can report, then you cannot create pre-fab content that will work with all devices, and therefore you can't create tight integration without extensive manual effort. Every exception requires manual effort because it can't be assumed up front. Every optional piece of functionality cannot be assumed up front and requires a much more complex dynamic readjustment to what is available, which pretty much means that individuals will never create fully reusable content because they'll never have all of the variations to test against.
That's really what I'm trying to say.
So a common protocol that just defines the words/sentences exchanged, and maybe indicates some basic semantic info at the individual data point level, isn't going to change the situation. But someone people keep thinking it will.
The only thing that would change the situation fundamentally would be the definition of that higher level semantic content, done very well and ubiquitously implemented, so that we know not only is this a thermostat, but it's a thermostat that followed very well defined rules as to how it reacts, what states it has, what functionality it can expose, and so forth. When you have that, then you can start to get real integration going with a lot less work.
We've spent well over a year now, maybe almost two now, creating such semantic abstractions for CQC and standardizing drivers to implement them. It's been a huge boon for simplifying system setup. But, it has all of the issues I mentioned above. No hardware manufacturer is going to specially implement some basic level of functionality required to meet our requirements, and those requirements cannot be absolutely bottom of the barrel and completely open ended or they become a standard only in name, not in fact (which is often the case.) So a lot of hardware cannot realistically meet those requirements and cannot be supported. And some that have the functionality have such ratty protocols that they are difficult to really support in a clean way, and it requires heroic programming to fake our high level semantics in the driver itself and try to force the device to follow along.
If you don't have a good, at least mid-level definition of all devices, what they can do, what states they can be in, what they can report, then you cannot create pre-fab content that will work with all devices, and therefore you can't create tight integration without extensive manual effort. Every exception requires manual effort because it can't be assumed up front. Every optional piece of functionality cannot be assumed up front and requires a much more complex dynamic readjustment to what is available, which pretty much means that individuals will never create fully reusable content because they'll never have all of the variations to test against.
That's really what I'm trying to say.
Dean Roddey
Senior Member
ChrisCicc said:
Maybe I'm misunderstanding, but that's a fundamental aspect of any automation system, based on two core facts:
1. The system can talk to devices that use different protocols
2. The system allows the user to manipulate the devices under control
That's all that is required to achieve such functionality. I can react to changes in one device and I can send commands to other devices in response. That doesn't really require anything formally defined as translation. It's implicit in the fact that every device driver provides an inward face that talks the system's internal view of devices and an outward face that talks the device's specific language.
pete_c
Guru
I tried and it didn't work for me relating to multiple buildings environmental management with the assumption my costs for said management would be lesser if they used same methodologies / products.
I did run into uniqueness of the nuances of using one product that wouldn't talk to another product concurrent with the uniqueness of that vendor building management.
Going to largest vendors in the country (many dog and pony shows) of said technologies showed me that they had most unique methodologies and that each one stating that they had the standards of communications / protocols that were industry standards (they did but added their own stuff) they had created. (well that and power, money domestic / international geopolitical IT issues).
Look at the reinvention of the thermostat, light switch, light bulb, refrigerator, et al.
The light switch original function was to turn on and off a light. Well too what about that light?
Today my Leviton HAI OPII panel is primitive and slow by today's world of IT.
The "units" on it whatever the methodology of communications (protocols) look the same to me.
The "units" that are talked to turn on a lamp or they turn off a lamp.
My software does similar and it can be faster or slower than the OPII. (well similiar to Dean's and Chris's products and the other automation software that we see here on Cocoontech).
-----------------CUT HERE-------------------
Just got an email this morning from EH.
They have written a document presenting 10 rules relating to automation for the home. (but they didn't chisel them into stone).
-----------------CUT HERE-------------------
It does talk to many more conduits of communications all simultaneously and presents itself with a single all inclusive gui.
That is expected because the user's / clients of said software see it as one product and nothing more.
The users of the software do not see that "grey" area under the main engine that talks to multiple protocols new and old. (well to one widget on their phone).
Many assumptions are made; each unique.
It is very difficult to keep up because each protocol makes the assumption that they are the end all means of an automation device. ("me first").
I do see multiple attempts at some sort of commonality; but really where's the return on investment to the multiple of companies saying that they have invented the product (well rewriting history with new patents and such).
We end up having to just utilize a product (application/firmware) whatever it may be than can talk multiple protocols to multiple devices concurrently presenting itself to the user as a singular type device and asking that software author about this and that "automation" communications protocol.
I have read many times; "well if it doesn't talk this" then its really not "good" at automation. Too we have now folks (always been around) that just stick with one product or protocol for automation with one company and just keep purchasing said mfg's products. They know its going to work or make said assumption and don't really care about anything else.
I did run into uniqueness of the nuances of using one product that wouldn't talk to another product concurrent with the uniqueness of that vendor building management.
Going to largest vendors in the country (many dog and pony shows) of said technologies showed me that they had most unique methodologies and that each one stating that they had the standards of communications / protocols that were industry standards (they did but added their own stuff) they had created. (well that and power, money domestic / international geopolitical IT issues).
Look at the reinvention of the thermostat, light switch, light bulb, refrigerator, et al.
The light switch original function was to turn on and off a light. Well too what about that light?
Today my Leviton HAI OPII panel is primitive and slow by today's world of IT.
The "units" on it whatever the methodology of communications (protocols) look the same to me.
The "units" that are talked to turn on a lamp or they turn off a lamp.
My software does similar and it can be faster or slower than the OPII. (well similiar to Dean's and Chris's products and the other automation software that we see here on Cocoontech).
-----------------CUT HERE-------------------
Just got an email this morning from EH.
They have written a document presenting 10 rules relating to automation for the home. (but they didn't chisel them into stone).
-----------------CUT HERE-------------------
It does talk to many more conduits of communications all simultaneously and presents itself with a single all inclusive gui.
That is expected because the user's / clients of said software see it as one product and nothing more.
The users of the software do not see that "grey" area under the main engine that talks to multiple protocols new and old. (well to one widget on their phone).
Many assumptions are made; each unique.
It is very difficult to keep up because each protocol makes the assumption that they are the end all means of an automation device. ("me first").
I do see multiple attempts at some sort of commonality; but really where's the return on investment to the multiple of companies saying that they have invented the product (well rewriting history with new patents and such).
We end up having to just utilize a product (application/firmware) whatever it may be than can talk multiple protocols to multiple devices concurrently presenting itself to the user as a singular type device and asking that software author about this and that "automation" communications protocol.
I have read many times; "well if it doesn't talk this" then its really not "good" at automation. Too we have now folks (always been around) that just stick with one product or protocol for automation with one company and just keep purchasing said mfg's products. They know its going to work or make said assumption and don't really care about anything else.
Dean Roddey
Senior Member
But devices on different protocols can inherently 'talk' to each other in a system where all drivers are internally (within the automation system) using a common representation of the devices, which would be the case in pretty much any automation system. In order for the automation system to function without having every bit of it understand every device type and their protocols, all automation systems translate device specific data and commands into an internal. common format. That internal, common format is essentially a translation mechanism (a lingua franca), not specially because it was created to provide that functionality, but just as a fallout of the natural requirements of any automation system to be able to internally expose all devices in a common way. So any automation system can provide this capability.
123
Senior Member
I think you two are in agreement but saying it differently. Perhaps I can <ahem> translate your respective thoughts.
I press a button on a UPB keypad. The transmitted link is heard by:
- a group of UPB lights which triggers them to turn on
- an HA controller which triggers Zwave and Insteon lights to turn on
I believe this is a scenario that provides the illusion of "device to device" (what Chris said) but requires a multi-protocol HA controller (what Dean said) to perform the magic trick of having UPB "talk" to Zwave and Insteon.
I press a button on a UPB keypad. The transmitted link is heard by:
- a group of UPB lights which triggers them to turn on
- an HA controller which triggers Zwave and Insteon lights to turn on
I believe this is a scenario that provides the illusion of "device to device" (what Chris said) but requires a multi-protocol HA controller (what Dean said) to perform the magic trick of having UPB "talk" to Zwave and Insteon.
