Replies: 5 comments 1 reply
-
|
I had idea to develop similar CAN VSCP adapter but my Viessmann Vitodens 100 gas boiler has very limited version of the OpenTherm protocol. |
Beta Was this translation helpful? Give feedback.
-
|
I think that can be a good idea. For VSCP if one want to use class.control,type. on to turn something off that is OK. It's up to the implementor to decide how he/she use the events even if such a choice may be confusing for most of us . The same is true for events in other classes. Duplicates are OK and there will always be many different ways to use the events that are available, and even construct your own. "You have to know what to expect to interpret what you get". Thats the only rule. So it is OK and a good idea to construct a class for HVAC equipment as long as it is general and not vendor specific and is needed. Please suggest how you think it should be built and the types that would be needed. Not my field. A "HVAC ON" and "HVAC OFF" without some extra special data may IMHO don't contribute much to the stuff that is already available. But you have probably other thoughts an ideas on the subject I guess. Let them flow. :) The only area I am not so keen to have variants in is for measurements. It destroy a lot of the plug and play thought behind the construct. You will have to argue hard to add a type that is just used for a measurement and is not defined in the measurement classes. |
Beta Was this translation helpful? Give feedback.
-
|
These are events, defined in the OpenTherm protocol (it seems to have a range of events covering all possible situations in HVAC systems)
|
Beta Was this translation helpful? Give feedback.
-
|
As you wrote initially VSCP can do all of these as it stands today. The thing with this protocol, and most other, is the low abstraction level. Nevertheless it works good for it's purpose and does the job. But why use VSCP then and not stick with a working and mature protocol instead of a marginal unknown protocol like VSCP. I may be wrong. I often is. Convince me if you thing thta is the case. |
Beta Was this translation helpful? Give feedback.
-
|
HVAC is just one subsystem of a larger whole. You've made the VSCP so that it has a broader perspective (and I like that about it, it's a shame I found it so hard to find, and it's not more popular). Including the HVAC class as a subset of the VSCP would allow for greater interoperability and unambiguous identification of events from such devices across the network. Now if, for example, I wanted to set the temperature of radiators or hot water I would most likely send a VSCP_TYPE_CONTROL_BIG_CHANGE_LEVEL event, which is very abstract, but I cannot indicate in it that I am setting the temperature, and its fractional values need to be described in the documentation, because I don't know if this sent number should be divided by 1, 10, 100,.... or maybe multiplied. I also do not know whether the unit is degrees Celsius, Fahrenheit or Kelvin. And so I would know all this without looking at the documentation. Using the measurement class (VSCP_TYPE_MEASUREMENT_TEMPERATURE) for this will in turn be confusing, because I am not sending the value I measured, I just want to force it to reach that state. Another case: currently if I want to quickly identify that a VSCP event came from some HVAC device I should put it in a common zone/subzone, and so the HVAC class would allow to clearly identify that the event came from e.g. a fridge in the kitchen zone, or a boiler in the zone - boiler room, and maybe - thermostat in the living room zone. But maybe that's just my weird craving. But I would still like to do it better with VSCP events, because it is a better, more flexible and cooler protocol than the others :) And I'm impatient with documentation :) |
Beta Was this translation helpful? Give feedback.
-
|
First of all I have to express how glad I am for disussions like this. It has not been a lot of that for some years now. Much of VSCP comes from discussions like this and a lot of people wanting to do things just like you are here. Generally I think that if it is obvious that a functionality is already there (in VSCP) it should not repetead. Or at least if there is not a good reason for doing so. Measurements are a typical example of that. If creators try to use measurement classes when they send out measuremnet values it is simple en logic for others to understand and for other devices to hook on in a plug and play way. You can add a display, logger etc in a simple way and as long as the new device sending the data use VSCP it can be interchanged by another brand or type and everything will still work. So the same is true for setting a value. CLASS1.SETVALUEZONE can be used to set values in a typesafe maner. Actually I got a little confused here, why is'nt there a CLASS1.SETVALUE? But it is't there beacuse of the lack of "addressing". Anyway CLASS1.SETVALUEZONE can be used to set a temperature for instance. It is a bit limited in value size and precission with two bytes less for "the value" compared to a measurement but will work for most situations. I would definitly use it though to set the temperature of radiators or hot water in cases like yours. For myself I usually end up setting setpoints in registers anyway. In your last case. The originating device is clearly identified by the GUID, or the nickname. GUID and nickname is tightly coupled so once found/read from a device GUID will uniqully identify a device. So you know what device that was sending the measurement, this is used in decision matrices also. For example I have a booiler controller in our house Raspberry Pi 5. A Kelvin NTC10K board measures temperature in the boiler and send out Turn on/turn off events continiously around the configured setpoint. The decision matrix of a Paris module triggers on the events and set/release the relay to the heater and confirm the state of the relay. You can actually see this live with mosquitto_sub -h mqtt.vscp.org -u vscp -P secret -t vscp/25:00:00:00:00:00:00:00:00:00:00:00:06:01:00:03/#When I want to change the setpoint I have a web-application that writes the new register values. Same if I want to turn things on or off. I use node-red to display and log values for most of my stuff. It would be easy to add a display that shows current values. For manuals we all hate them. And writing them is even harder because you know everyone hates them and still needs them and noone can find the things they are looking for in the anyway... :) HVAC calls is great if we can add events to it that are not general for the VSCP protocol and if they contribute to the workings. And again, if I don't get what you are speaking of, donät give up. I have a thick and may need some convincing... :) |
Beta Was this translation helpful? Give feedback.
-
What do you think about creating a separate protocol class for events generated by HVAC equipment, based on OpenTherm, KM-BUS (Viessmann) or other specifications? Of course, this can already be done, using events from the classes: control, information, measurement,... but if this was collected in one class I think it would be more unambiguous.
Beta Was this translation helpful? Give feedback.
All reactions