With the UNDEF idea, in the modbus binding we found it best to have that as a configurable option.
For transforms, see modbus again for an example (the raw data there is 16-bit word). Read and write are separate, think scaling.
CRC - I understand put it off till later and ignore for now but you can’t do that for writing. I’d suggest at least planning how to dovetail into writing.
I may have misunderstood your thing structure.
I was imagining -
A Bridge, specifying serial port. There may be more than one of these.
A umm station Thing, specifying a particular packet structure, device id, etc. Potentially several of these.
Each Thing has many channels, e.g. raw payload, simple switch, selected parts of payload. This is where transforms would apply. In my view, it is these channels that have the flavour of Dimmer or Sensor etc.
I suppose that summarizes as
Bridge = hardware
Thing = protocol
Channel = data
Using writing to Pelco as an example, envision setting up Bridge for COM5 9600 etc.
Set up station thing for pelco protocol, camera 7
Set up another station for pelco, cam 9
Incoming data gets routed via channels to separate Items, by way of each thing analyzing the packet (broadcasts may be llowed as defined by protocol)
To write, OH commands a channel, the thing formats, transforms,adds id, adds CRC, passes to Bridge.
EDIT - a structure as above, with multi stations sharing a bus, make obvious it would be desirable to define “protocol” or “packet structure” or whatever you call it in a shareable way. Perhaps an external file, info encoded as you like but JSON might work.
I am not going to take that route and create a nightmare where if someone wants X protocol I need to spend hours on a protocol I don’t even own. Protocols should go into their own bindings in my opinion and the serial binding should be a fall back GENERIC binding to use when nothing else better is implemented. There would be hundreds if not thousands of serial protocols in use and if someone wants to give up the rest of their lives implementing them they are welcome.
I guess my proposal would be summarised as:
Bridge = hardware serial port which we agree on.
Thing = Different Filter types. A way to filter out the data you want from a stream that comes from the bridge and convert it to the data you really want. The name of the thing is what the filter is designed to give the end user.
Channel = data that is filtered and already in the format Openhab needs with no need to transform it.
We could say there are two groups of serial devices, 1 that only have a single sensor or a small number of controls like a Fan speed controller. It is stupid to create a separate binding for this, which is where the serial binding best fits.
The second type of serial devices like Pelco that have a large number of control ability say more than ten channels from a single device. This is where a separate binding should be created with a better or more standard use of the THING concept. However for people who only wish 2-3 controls it should be simple to use the serial binding to get what they want…
Example a surround amp with 50 different controls defined but we only have 1 user of Openhab that is happy if they can get control over 3 of them, ie POWER, INPUT and VOLUME
Of course nothing is stopping someone from spending countless hours creating 50 things for the 50 controls, I just believe someone will be happy that what they need is possible very quickly to get the 3 basic controls.
Perhaps a thing type could be defined to filter out 8 switches from a byte. Each bit goes to its own switch channel and it also has a string channel to display the full packet with.
Does this make sense? Should it be called “Serial Filter Binding” or something other than Just Serial? Have a better idea how a simple and flexible binding can be created that does not require huge up keep?
Absolutely, poor choice of word by me - let’s call it “format” which might describe the shape and size of some packet in terms of “match this header”, “next is three bytes of data”, “next one data”. A sort of REGEX essentially.
I think that would have you reinventing wheels. Applying transforms at channel level is already implemented and understood, and gives users lots of flexibility e.g. I want data “banana” represented by a CLOSED contact in OH.
Following from earlier example, the three bytes of data arrive here as they are, ready for transform.
In general, yes I agree, keep it simple. If possible and practical, design in structure to allow people to make their own knobs and whistles.
I think Pelco makes a pretty good example.
I am NOT suggesting that you write Pelco protocol into a general Serial binding!
But the packet has address, header, multi data payload, and error check sections.
I’m really not sure at all how to go about it, but a configurable means to divide up and match or route such chunks is I think what you plan?
Yes that is the idea to use ‘Things’ to filter/parse the incoming serial data until it matches a specified format. Being able to do easy strings like ‘banana’ to more advanced packets of bytes like Pelco.
Yes you get to choose from something like the following:
MATCH (match only exact value user gives)
IGNORE (match all values)
ROUTEx (Send data1 to the channel1, send data2 to the channel2…)
The exact how and finer details I am still working it all out as I like to see what packet formats people are wanting to use and sketch an idea up based on this information. CRC and checksums can be added later, but the IGNORE feature which is also needed for multiple other reasons could be used.
If there is an elegant way to add 50 Pelco devices to Openhab, I would love to learn and see an example for my own knowledge. I feel that as Openhab moves towards a graphical UI it does not hurt to have another way to do things.
Comment - me harping on the CRC thing is not about providing an immediate solution. For sure, we can ignore on read.
If anyone is interested, I imagine they will be able to channels of raw packet topped and tailed, channel of checksum field, run their own script.
I’m thinking about write, where you cannot control the target’s expectations.
Say the Thing is assembling a packet e.g. templated fixed fields + data from assorted channels, it is “difficult” for some external user script to calculate CRC type addon across an internal binding creation.
I’m saying plan a means to deal; top of head, aĺlow a user script to be insertable in the process. Rather like a transform between the Thing’s completed assembly and the Bridge.
That’s different to channel transfoms massaging e.g. ON into x00FE
Yes I agree reads are easy(ish) compared to writes.
Writes with CRC could be handled in multiple ways including using a full string created and sent to the RawString thing type, the same way the current binding can be used to do this already. I don’t see an issue with that request.
If the CRC/checksum is a common method used by multiple protocols it should be added into the binding in my opinion and not in a script. Sometimes turning a script into a built in Java function is only 1-2 hours of work if the framework inside the binding has been created to be flexible.
The other thing that can be a blocking issue for controlling a device is the requirement for ACK(nowledge) messages. Some device will keep spamming the serial bus thinking the packet was lost and needed to be re-transmitted if Openhab does not respond with the correct ACK packet.
These are the kinds of use cases I am looking for right now so I can develop the idea into something more concrete and create an empty binding with no code behind the controls for people to look at. But I simply do not have the time to do this for at least 2 months.
The ACK point is important. I’m guessing some variants will also reflect some of the data or a sequence number, blah.
Again I think about writing - where OH could expect an ACK. Like CRC, simplest is to ignore but we ought to think how it might be implemented and/or provide a mechanism for user to implement. The rules of the game may require awaiting an ACK before sending next packet. I suppose an actual implementation might toggle a channel on the Thing “awaiting ACK / all clear”. How to manage a NACK - eek! Also must have a timeout.
In truth, both read and write ack-ing could be managed reasonably well outside of the binding. Maybe consider that sort of thing as “protocol” business, best left to external code (or a dedicated binding like Modbus).
Speaking of Modbus, you may find it worth a peek at that binding. It is an apparently simple protocol which spawns complexity at the interface to openHAB because of the way it gets used.
But it will include all the elements we’ve discussed, not suggesting reinventing this but look for building blocks.
wildcards to receive values would be great. e.g. assign a temperature value to an item via the MySensors serial protocol:12;6;1;0;0;[VALUE]\n
Item Example:
Number Temp_1 { serial="SerialDeviceThing","12;6;1;0;0;[VALUE]\n" }
to set VALUE to Item Temp_1 if this pattern is received
That’s the general idea, except it will be things and channels. You’d somehow set up a kind of template in a thing 12;6;1;0;0;[VALUE]\n and have the value available in a channel to link to a Number thing.
I have a custom version of 2.4 that supports /r as a delimiter between messages, so it can use readLine (name ?). This makes the latency for each message to be much smaller. It would be good to see this as an option in the official binding.
Why did I do this? I use a arduino as an IR receiver, sending messages back via serial. The arduino is there to handle the unusual pulse signature of B&O ir codes. The delay in the stock bindings polling system makes it feel very slow when using up/down/left/right type actions.
Any update on the status of this migration? I’m using serial communication between an Arduino and a rPi for lights and buttons. I can test the binding if necessary.
Nothing has happened yet, been busy with other projects but this is still on the to do list. Finding spare time with a baby is difficult and now I have bush fires in my area that puts more strain on my “spare” time.
I read topic few days ago and now started to build a simple serial binding. I based this on the dsmr binding as I did with my vallox binding. First idea was to make it bridge->thing configuration as the initial plan was so that multiple things could support different data types/protocols. Now I think that this is not the way and we should only have one thing that handles the serial device and transformations with rules are used when handling the data. My questions are is there something that rules can’t handle and what are the absolute minimum that the binding should have included? For example what different settings should be made available.
I was thinking along the lines of a bridge to represent the serial port which supports a string input, string output and a trigger when data is received.
Things could be used to represent reading data from devices without having to use rules. A thing would support a simple regex match to update it’s channels if it matches the input string. A channel would support a transform to transform the data before updating the item.
Although all of that is much more than is required for my simple use case of receiving a string which I currently check with a rule.
Just wondering if this is moving forward. I’m using it to control relays (KMTronic) and my electric curtains (Goelst). What I’m missing is rfc2217 support and proper handling of failures. If a USB device or socat device is disconnected it doesn’t reinitialize properly and CPU load goes sky high.
Yes @MikeJMajor is getting the V3 serial binding through the review process at the moment. So if your on V3 it is probably possible to get a build and help with testing.
but you can’t do that for writing. I’d suggest at least planning how to dovetail into writing.