A new version of the package node-red-contrib-socketcan (1.0.10) was published at 2021-03-14T14:17:24.860Z
Category: VSCP
Categories
21 years later
This is quite funny actually. Twenty one year after VSCP was born this man is almost perfectly describing VSCP infrastructure and thoughts.
Units for all measurements and conversion between them is now included in the autogenerated databases and in autogenerated JSON and XML files. Also ASCII and UTF8 symbols are included for each measurement unit.
The unit definitions and formats relay on the mustche format with JavaScript (pseudo) code for the conversion. Simple tools can be used in a project handle this. For this the default unit always is defined as
{{val}}
That is the value (which is a floating point value) is always substituted on it’s own by mustache. For the other unit’s for a specific measurement there are mathematical expressions added to convert that unit to the default unit. With this schema all units can be converted to every other defined unit by first converting it to the default unit.
As an example, for temperature measurements this looks like this
- unit = 0 (default) is Kelvin: {{val}}
- unit = 1 is Celsius: {{val}} + 273.15
- unit = 2 is Fahrenheit: ({{val}} – 273.15) * 1.8 + 32.0
- unit = 3 is undefined.
A helper for event display is <b>render</b> which for the moment is only defined for vscpworks but can have formats defined for other presenter software as well. The definitions for measurement renderings as an example looks like this today
<render>
<vscpworks template="
{{lbl-start}}Unit: {{lbl-end}} = {{unitstr}} [{{unit}}]{{newline}}
{{lbl-start}}Sensorindex: {{lbl-end}} = {{sensorindex}}{{newline}}
{{lbl-start}}Value: {{lbl-end}} = {{val}}{{symbol}}{{newline}} " />
</render>Mustache is also used here for variable substitution. More info is here.
You find the auto generated files here
Categories
State of VSCP
A short update from the VSCP makers. Yes me. The one and only. At least when it comes to development efforts on VSCP.
The work on the new VSCP Works version continues. It is a lot of dialogboxes and other stuff to do before the fun stuff can be implemented. But the work is moving in the right direction. The first session handling (event logger) for tcp/ip, canal and mqtt should soon be in place. The others, socketcan, udp, multicast, rest, ws1,ws2, rawcan, rawmqtt will take a bit more time to finish. The nice thing with this is that the transports all get a pluggable common API. Very easy to switch transport in other words and the possibility to build other functionality like reading/writing registers etc on top of this API. This code must be low level and is only dependent on C++ 11 and openssl.
But hopefully I can get some alpha code for VSCP works out soon now so testing can take place by the brave. It’s really the packaging that prevent me from doing this today. This work takes so much time.
Last Friday I decided to decided to give the Windows port of VSCP Works a try. It is now a long time since I been doing any development on Windows, but having been there for way over 10000h I thought this should be an easy task. I was wrong. Gave up. To some extent this giving up is due to me not having a Windows machine for development. I do this work through a remote desktop interface. Not optimal. But I will come back to this later again. There will be a windows port. Last Friday was not just the day to dig deep enough to make it real.
For the VSCP daemon it just sits and wait for release. I need to make some decisions on some low level issues and have some drivers to fix before it can go out through my old red door.
LoRaWan with its small packet size and speed is a perfect for VSCP (of course). I need some hardware to do some coding/demo with it. So if someone have a board or two (and a gateway) they have no need for… 😉
But writing “state of VSCP” does not help much in getting things ready for release. This have to be bye, bye for now, I have some coding to do.
As always I want to thank the sponsors of VSCP. Your support is of great, GREAT, help in this effort.
Take care everyone!
/Ake
Categories
#VSCP docs
Categories
CANAL wizard beauty
I am currently in the process of developing vscpworks+ a new version of the VSCP Works toolbox. This is something that has been in the pipeline for many years now as the old version is pretty old and outdated at this time.
The previous version was developed using the wxWindgets framework and I never quite liked it. It is non intuitive and hard to work with IMHO. But at the time when it was selected, QT, which was the alternative GUI framework, had strange licensing and a very unsure path ahead. Well a bad choice as it turned out.
The year before last year I removed all dependencies of wxWidgets in the core code of VSCP software. That was quite a rewrite I can assure you. Now it is dependent almost only on standard C++. Now when that has been done time has come for the rewrite of the VSCP works toolbox.
My goal is to handle all the standard pieces of the VSCP specification in VSCP Works. Many are missing just because I thought that the old project was a dead end and that there was no meaning in putting in to much development in that end.
So this is a rewrite also. A large project. (Help is welcome 😉 )
But it not about the VSCP Works rewrite this post was supposed to be about. It is about CANAL.
Many many years ago I did the CANAL specification and it’s API as an abstraction layer for CAN (CAN Abstraction Layer). The thought was to select something really low-end and build VSCP functionality on top that. Thus allowing VSCP to work on really low end devices and on high end devices. Nope there is no tcp/ip and json at that level. Sorry.
The CANAL spec has survived over time and is more or less unchanged since it was created. Companies like Rusuka and 8Devices and others use it for there devices. It’s main use here is of course as the VSCP Level I driver API. The last common denominator format for a VSCP low end device is outlined from the constraint set up by this interface.
On the client side, there is the VSCP daemon that use the API, but there is also C/C++ code available, Python code, node.js code and more. (See https:docs.vscp.org)
The CANAL specification has one method that I never used in my client implementations (because of the reasons above) but which I think is very nice and beautiful indeed. It is a method that allow a CANAL driver to tell it’s client how it should be configured. This method should be implemented for all CANAL/VSCP Level I drivers and is called canalgetdriverinfo.
Before I go in to how it works I need to explain how CANAL/VSCP Level I drivers are configured. It is simple. There are a only two items that need to be configured.
- The configuration string which is a semicolon separated string with driver specific configuration values.
- The flags which is 32-bit unsigned integer where each bit or group of bits can be used for configuration.
So for the simplest of driver both of thees could be empy and for a really complex driver there could be many many complex options.
What the canalgetdriverinfo method does is to return a XML structure. This structure explains each option both for the configuration string and for the flags integer. The thought is of course that a client software, as soon as it knows the path to the driver, call this method and parse the XML content and then can be able to support the user with the configuration of the driver. Easy and nice and beautiful.
The XML object is constructed in such a way that it can present the configuration of the driver as a step by step wizard. So by going through the steps the driver can be set up in a way an end user (yes it could be a machine to) wants.
So in vscpworks+ when a user defines a CANAL/VSCP Level I driver this option will be present. Making it very easy to configure drivers without looking for documentation topics. The code is encapsulated in a couple of C++ classes so this code can in turn be used by other projects including Python and node.js code.
Just simple and beautiful as VSCP itself.
vscpworks+ qt version on the way.
I am working my last hour now for this year and will from this point have a few days off. It’s been a strange year and I think everyone is hoping for a better 2021.
I am currently working on porting and testing the last bits for the 15.0 VSCP & Friends release and hopefully we will see this released in the beginning of the new year. Lots of changes. I am rather excited.
I just want to wish everyone here a happy new year and also want to thank sponsors and everyone else that helped during this year. This support has been very important and the key to get energy to work on with the everyday tasks. THANKS!
Take care out there and I will hopefully see you all again in 2021.
node-red-contrib-socketcan (1.0.9) was published at 2020-12-15T16:22:14.697Z
Updated bcrypt,