This is release 1.12.0 of VSCP & Friends
From now on releases will come closer on all platforms. There will not be as much fuzz about therm as before.
This release may not be the choice for a critical installation as it contains many changes from the previous release.
Enjoy
/Ake
A new VSCP firmware is released as version 1.6.0.
The main difference in this release is that the segment controller check has been removed. This means that the node control that was present in register 131/0x83 is now replaced by the error counter. Thus read the current error counter value from this register. Reset the error counter by writing anything to the register.
With the same segment check removed a node that is moved from one segment to another now must be manually initialized after it has been started up.
Previously one control byte was used to check for initialized EEPROM. Now this is two bytes. The callbacks for this purpose has therefore been changed.
///////////////////////////////////////////////////////////////////////////////
// setVSCPControlByte
//
void vscp_setControlByte( uint8_t idx, uint8_t ctrl )
{
if ( idx > 1 ) return;
eeprom_write( VSCP_EEPROM_CONTROL1 + idx, ctrl );
}
///////////////////////////////////////////////////////////////////////////////
// getVSCPControlByte
//
uint8_t vscp_getControlByte( uint8_t idx )
{
if ( idx > 1 ) return 0;
return eeprom_read( VSCP_EEPROM_CONTROL1 + idx );
}
Another callback has been added that do the actual initialization of the EEPROM
///////////////////////////////////////////////////////////////////////////////
// vscp_init_pstorage
//
void vscp_init_pstorage( void )
{
init_app_eeprom();
}
An addition is added if you define
VSCP_FIRMWARE_ENABLE_ERROR_REPORTING
which will give access to a method for VSCP standard error reporting
/*!
Send error event (CLASS=508).
http://www.vscp.org/docs/vscpspec/doku.php?id=class1.error
idx can be used to identify the internal part ("submodule") that was the
origin of the error. Both zone and sub zone are always set to zero.
@param type This is the VSCP type
@param idx Index to identify possible sub module. Normally set to zero.
@return True if event was sent.
*/
#ifdef VSCP_FIRMWARE_ENABLE_ERROR_REPORTING
uint8_t vscp_sendErrorEvent( uint8_t type, uint8_t idx );
#endif
Just remember that over CAN it is no use in reporting communication problems as doing so will most likely make them worse.
Another addition is added if you define
VSCP_FIRMWARE_ENABLE_LOGGING
which gives access to a method for standard VSCP logging.
/*!
Send log event (CLASS=509).
http://www.vscp.org/docs/vscpspec/doku.php?id=class1.log
For loging first send Type = 2(0x01) Log Start then logging events and when
log is closed send Type = 3 (0x03) Log Stop. To log several things use a
unique if for each and open/close each.
@param type VSCP logevent type.
@param id Identifier for the logging channel.
@param level Loglevel for this log event.
@param idx index for multiframe log event starting at zero.
@param pData Log data (Allways 5 bytes).
@return TRUE if event was sent.
*/
#ifdef VSCP_FIRMWARE_ENABLE_LOGGING
uint8_t vscp_sendLogEvent( uint8_t type,
uint8_t id,
uint8_t level,
uint8_t idx,
uint8_t data );
#endif
As always the Paris project and the Kelvin NTC10K project can be used as reference code.
The release is available here.
Enjoy!
/Ake
This is simple. Every protocol that is entering the scene today is dubbed an IoT protocol. Hmmm… are they really… or are they transport mechanisms (which we already have plenty of) or is they just useless vertical solutions (well not useless for the company who made it). And hey… it does not have anything to do with Internet or wireless. It’s about connecting things.
So
1.) Does the protocol connect things together? If so, item under test is a candidate for an IoT protocol.
2.) Ask ten people in ten different areas of the earth without contact with each other to send a measurement of there current temperature over the protocol. If the receiver on the other end know what he/she receives from all ten the protocol is a candidate for an IoT protocol.
3.) Ask the ten people to send an ON command and then an OFF command to turn on/off a lamp at the receiving end. If all actually does this the protocol is a candidate for an IoT protocol.
So 1+2+3 and success on all, yes and hurray, it’s an Iot protocol. If not it may still be a useful protocol for other things.
Åke Hedman
Paradise of the Frog AB
If there was time…
… then I would have put more time on UX components for VSCP. YES the infrastructure is there. We where one of the first with a websocket interface to interface UX components. We have the REST interface and the tcp/ip interface. I would dare to say there is no system/framework available today that makes it easier to visualize result from sensors out there and also to interact with them in such an easy way. A few lines of code is all that is needed. Some demos are here (User:admin Password: secret).
But we (the VSCP world) don’t have users that have the skill or interest to take this further. That users would do that was my hope when I once set this up. That others, interested in user interface design, would take over the job. Needed because I am and will always be a low end developer doing drivers and other nitty gritty low end things. You need other skills for UX design then I have. It is a wast if I try to do this. Well it was a waste me doing the Javascript libraries. But someone had to do it so I did it.
I was disappointed of course. This could have been great and a lot of fun to. Giving lots of credits to the ones that worked with it. Probably money to.
I have asked for help so many times and do so one last time. So
Well there is plenty of things to do. No need to list them really as it is apparent that most UX components are missing. I will still try to come up with a list in order of importants what I would have liked to see being realized.
1.) Samples, samples, samples and more samples using the Javascript library , the websocket interface and the REST interface. Just to show what is possible and as a tool for others to build upon.
2.) More HTML5 websocket widgets.
3.) I am not a big fan of OpenHAB, “the big elefant”, but one thing I have always liked in it is the user interface component they came up with early. The demo site is apparently down at the moment but here are some screen shots
In my world this is typically something defined in an XML file and read by an app. which put up the interface. The XML file can be fetched from a VSCP daemon that is localized through its multicast interface or is pointed out by the user. The XML file can be served by the web server or through the websocket interface stored in a variable.
Inside the XML file there is a hierarchy of pages. Each page consisting of one or several lines.
Each line is a HTML5 element. Looking at the switch above
a line can be single line (others can be multiline or page) and in this case a widget to the left (the lamp), the text in the middle (which also is a widgets, the statebutton to the right. So in this case the text may be static but the lamp widget show the actual dynamic state for a lamp or something and the switch actually do the toggle of that state.
A line like this have the same general components but the arrow just bring up a new page.
And a line like this has the same components. Here the temperature is shown dynamically but the iconic thermometer to the right could be used to show alarms etc or that could be done in the text.
Not a big thing really to implement on an Android, IPhone or desktop machine but something that takes time and needs a feeling for UI design to be usable.
They have a new version now which is demoed here and which dynamically adopt to the screen size.
4.) I have a quite similar project, Merlin, that is a drag a HTML5 component to a page and thereby adding active UI components to that page. I never get time to finish it as it looks.
Live here (User:admin Password: secret).
A typical example shown here with active buttons places on a floor plan of a house. Right click on the component to set it up. When done, generate the web page.
5.)The MDF (Module Description File) of VSCP defines a module and tells how it can be configured. The MDF nowadays also contains the possibility to set up wizards to help user to do specific setup tasks step by step in a generic way.
As all VSCP modules have information about this MDF in them they all have the ability to tell the world how they work, what they can do and how they should be setup to do just that. Yes gatekeepers prevent everyone from messing around with a module. But that is another issue which we leave out here.
An iBeacon or an EddyStone/physical web capable machine can send out the MDF URL for the world to see. So can a NFC equipped device do when taped. So a machine that see this can get information that there is a device with certain capabilities available and it can from there open up a UI that allow the end user to discover the unit’s capabilities and also configure it to do the things it is designed to do. This could be limited to just get information from the node or even status from it or to really go into it and be allowed to edit it’s configuration.
To understand this it is important to know that VSCP with it’s register abstraction model and the MDF allow for it’s unique one application can configure all functionality.
So with this UX functionality a user of some equipment can set it up in a uniform way. He/she will be comfortable with the setup procedure from other equipment. But it can be used by a service technician to configure/diagnose something when he/she is out on the field. Of course it would also be possible to do this remotely equally good when needed.
A general setup/configure/presentation interface for VSCP that is. Target platforms phones/tablets/desktops.
7-9999). Well they are there to of course. But we take them another day…
Ake Hedman
Maintainer of VSCP
Developers, we all use tools. So does VSCP & Friends to of course. Everything else would be stupid. Reuse is the thing in an open source world. Yes in the closed source word to. The two most important tools we use are wxWidgets and Cesanta Mongoose.
The choice of using wxWidgets came about because we wanted everything to work cross platform back then. This was actually a hard choice. Two competing systems where available. QT and wxWidgets. The problem at the time was that QT was not free and open on the Windows platform so in the end the choice to use wxWidgets was on that had to be taken. Well I like QT more. But to rewrite everything. A million lines of code. Forget it. In the end it does not matter much anyway.
The other tool is the Mongoose library. This is a communication library (and a webserver) that I strongly can recommend. Well it is actually not a library. It uses amalgamation. So instead of linking in a library you add the project files. Convenient and easy. So the mos of the tcp/ip stuff we use are built on this tool.
Well it is great, works great, but is quite badly documented. Have few examples. Furthermore it was previously divided into mongoose and net_skeleton. This was how it was when I discovered it. But when I released the code net_skeleton was transformed into fossa and changed in many, many, many. many ways so parts I rewrote for fossa leaving the parts that used mongoose as they had a dependency on net_skeleton and then the guys over at Cesenta decided to move everything from fossa back in mongoose… Yepp you all understand. It’s was a mess.
So now if I want to port to the new mongoose code it’s a hard work to do. It has been changed a lot. It’s a major project I can tell you. A MAJOR PROJECT!
Well, even if this is really bad practice from a tool maker, REALLY BAD, this is good tools. So one only can hope that this moving around has come to a stop now and they will say as good usable tools.
So this major rewrite is what I do now. fossa and net_skeleton is going away and mongoose is coming in. A change that affect almost every file in many, many places, Changed calls, changed parameters, changed functionality really put me to the test. Yes this will take some time to complete. And I will probably still recommend the tools. They are great. And maybe the changes they did was needed in the end. At least I think things are a bit more easy to understand now than it was before.
So now you know why it’s so quite form our corner… It’s called hard work…
Sometimes, and especially if your device is a low end device, it can be nice to publish measurement events from the VSCP daemon to it as plain numbers. You can do this with the simplify feature.
First look at the driver entry in /etc/vscp/dm.xml
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT2</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session2;publish;vscp-pub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
We see that this driver defines a publishing MQTT channel with
Nothing strange here. Normally VSCP events would be available if you subscribe to the topic vscp_pub on this broker. On the console typically like
mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
This is just the same as we described above. But now lets define a simplify variable like (/srv/vscp/variables.xml or in the web interface of the VSCP daemon).
<variable type=”string”>
<name>MQTT2_SIMPLIFY</name>
<note>Feed temperature measurements to “the thing”</note>
<value>1040,6,0,1,0,0</value>
</variable>
When the MQTT driver loads it looks fore variables named like it’s name + “-” + keyword and configure itself from the variables. This configuration actually overrides the configuration done in the diver configuration string.
It also add extra configuration possibilities and SIMPLIFY is on of them so
MQTT2_SIMPLIFY
is a variable with name “SIMPLIFY” that is destined for the driver with name “MQTT2”.
The content of a simplify variable specify the event we want to send on the MQTT channel as a plain number. In our case we have
1040,6,0,1,0,0
which boils down to
You can use CLASS1_MEASUREMENT and CLASS2_MEASUREMENT_FLOAT also if you which for this functionality and the format for them are here.
So now when you restart the VSCP daemon CLASS2.MEASUREMENT_STR events will come out as plain numbers on the MQTT channel. We can test this in the TCP/IP interface by sending
send 0,1040,6,0,0,-,0,0,0,1,0×35,0x35,0x35,0x2e,0x30,0x32
which will come out as
vscp-pub 555.02
if you subscribed using mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
You may just want to send plain numbers instead of a full VSCP event to the VSCP framework. Typically this can be some stupid device that just is capable of sending out plain numbers. The simplicity mode can make these kind of devices a bit more useful also. YES you want at least the unt of your measurement to come along with your data in a standardized way.
To use this feature we us the first driver entry we specified
<!– Level II MQTT Driver –>
<driver enable=”true” >
<name>MQTT1</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session1;subscribe;vscp-sub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
Here we subscribe to a MQTT channel vscp_sub on the broker located at 192.168.1.9 on port 1883. We name the session “session1”. Remember that all drivers MUST have a unique session name.
So things publishe form other devices on topic vscp_sub will be received by the driver and normally this is VSCP events on the standard string form
send head,class,type,obid,time-stamp,GUID,data1,data2,data3…
you can read mode here about this format used n the TCP/IP interface of the VSCP daemon among other places.
But now we want to send just a number and get a VSCP events. So for this we use the simplify feature again.
We start out just as above by specifying the SIMPLIFY variable. As you see we now referee to the first driver entry MQTT1
<variable type=”string”>
<name>MQTT1_SIMPLIFY</name>
<note>Allow for sending plain numbers </note>
<value>1060,6,0,1,0,0</value>
</variable>
Only 1060 is different than above, We could have used 1040 here alos to get CLASS2.MEASUREMENT_STR event but to be not to repetitive we use CLASS2.MEASUREMENT_FLOAT for this example.
And using VSCP Works to check the incoming event gives the expected result
If we set CLASS2.MEASUREMENT_STR (1040) instead we got the same end result
And you can use one of the other measurement types also of course. Read the docs.
Well that was it for this time. The full driver info is here.
The MQTT driver for the VSCP Daemon is a way to connect VSCP to things communicating over MQTT. Well it’s just as easy as 1-2-3 to do so. Just follow this instruction.
Suppose that we want two MQTT channels. One that publish content to a broker and one that subscribe content from a broker channel. Of course we can have as many as we like. Just add more driver entries if you need more. There is no practical limit.
So for driver additions we add the following driver enteries to the vscpd.conf file (/etc/vscp/vscpd.conf on Linux and /programdata/vscp/vscpd.conf on windows).
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT1</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session1;subscribe;vscp-sub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT2</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session2;publish;vscp-pub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
Both have there own unique names, MQTT1 and MQTT2 as they should. Paths are set to the driver location. Windows user need to point this path to the installation folder. The GUID is set to all zeros meaning the driver will use the GUID of the interface. We are fine with that in this sample but for most cases it is better to set a unique GUID.
Then we have the configuration string and it is different for the two driver entries. We look at each driver on its own from here,
The configuration string looks like this
session1;subscribe;vscp-sub;192.168.1.9:1883
That is we create a subscription channel, that is a channel which subscribes on content from a MQTT broker, and in this case expects VSCP events on the standard text form coming in on the channel. The broker is at IP-address 192.168.1.9 and using the standard port 1883. The topic we are interested in is vscp_sub. That’s almost it. We need one more thing. We need to name the session for our communication with the MQTT broker. In this case we set the session name to session1. Remember that this session name must be unique in each driver entry.
Restating the daemon and we are ready to go
Using mosquitto_pub we can now send MQTT events to the VSCP system
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,10,6,0,0,-,0x88,0x82,0x0A,0x09”
which comes in as 25.68 degrees Celsius from sensor 1.
Data
This section can be skipped if your not interested in how the data is coed.
This format is fully described in the data coding section of the specification but we give a brief explanation of the event data here also (but you should read the spec. for a comprehensive understanding). The event is CLASS1. MEASUREMENT, Type=6, Temperature. So we have a temperature measurement. Good to know.
It is a VSCP level I events. We see that from CLASS1. in the class name. This is a low end measurement event used in VSCP that can handle all SI system defined types. VSCP level I event have a maximum of eight data bytes as it is defined to be possoble to be handled by the smallest devices out there. Eight byte is not much but you can tell what type of measurement it is, what sensor of eight possible on a board it comes from, and what unit the measurement is give in. Not bad. Compare that to just sensing 44.20 over the topic.
The data can be coded as a string or a floating point value or in something called a normalized integer as here. If your device can handle floating point you should use that. But many devices does not have resources to handle floating point data as it costs memory. They ned the memory for other tasks. And that is where the normalized integer comes in handy.
As you see the data for the measurement is
0x88, 0x82, 0x0A, 0x09
The first byte of this data is the coding byte, here 0x88. In this byte fits information about the index for the sensor (bits 0,1,2), the the unit for the measurement (bits 3,4) and the type of data that follows (bits 5,6,7).
So in binary 0x88 is
10001000
which if we break apart the different fields become
100 01 000
OK We have a measurement value from sensor 0 that is expressed as degrees Celsius. Just need to know the value as well.
A normalized integer have a decimal point shift byte as its second byte and then the 1-6 bytes that follow are the actual integer value. So here the value is 0x0A09 (VSCP always store everything MSB first). Translated to decimal 0x0A09 is 2569.
The second data byte (0x82) says, if it has bit seven set, that the decimal point should be moved left in the number that follows with the amount told by the remaining bits. So in this case the decimal point should move two steps to the left which gives 25.62.
So the measurement value is a temperature measurement of 25.69 degrees Celsius.
Sending on/off
Everything is well specified in VSCP. So to turn something on or off is well specified of course.
To tun something ON one use the CLASS1.CONTROL, Type=5 in VSCP. To turn something off one use CLASS1.CONTROL, Type=6.
The event CLASS1.CONTROL is coded as 30.
Now to something that might look strange to VSCP newcomers at first. VSCP normally does not address things. WHAT!? you might scream out. Yes it does not. Instead it send a TurnOn event to devices in a zone/subzone. The sender does not know if the receiver is one or as man as hundred devices. It does not even care. It just send the event. It trust the transport mechanism to deliver the event to interested parties.
So for both TurnOn and TurnOff of the data format is
0x00, zone, subzone
So to turn something on in zone=1/subzone=2 we send
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,5,0,0,-,0,1,2”
and to turn something off we send
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,6,0,0,-,0,1,2”
Not to hard is it?
The configuration string looks like this
session2;publish;vscp-pub;192.168.1.9:1883
Well we recognize the confoguration string from above. The session name is “session2”. Remember it should be unique. and we publish to a broker instead of subscribing. The MQTT topic is set to vscp_pub.
So to if you subscribe to vscp_pub on the broker you get events from the VSCP system sent to you. You set filters to tell which events you want and do many other things.
Using the mosquitto_sub subscribing is
mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
which you can use for testing. But Arduino or Raspberry Pi also have MQTT libraries so you can take in VSCP events to them to, well or sening giving you access to the VCSP framework with web interfaces, diagrams, message routing and a lot more.
It may be simpler to use just VSCP and get the same advantages but this write-up is for those of you that use MQTT today.
Another part will follow describing a way to simplify message handing over MQTT.
Short answer or executive summary: You should not!
Longer answer:
VSCP is developed by one man. He is very old. Actually old guys like him can die any day. Just like that. Rule. Never trust a system developed by one old man. Microsoft, Google, IBM have many young men and woman on there teams and they will be there forever. Just like Ashton Tate and Altavista actually did… hmmm… or did’t they…
VSCP has no budget. No nothing. Not a single cent. There are plenty of other IoT/m2m frameworks that have a budget. And we all know what people can do with a budget. Right. Rule: Choose an IoT framework with a budget because every project needs one. We all know that. At least we should all know that.
VSCP have just few users. Ten or so? Less. Rule: Go for a system with many users. Users can help each other and also test a system so it gets better and better. Some users of some systems even contribute code. VSCP users does not do that. They usually rewrite code that is there because they don’t like the way it’s formatted or something like that. But not a big problem. As they are so few.
VSCP is just 2.5K flash and tens of ram implemented in a node. What can actually be done in 2.5K of code? Print “Hello World”? Rule: Real systems use 32M of ram and five times that of flash . At least.
VSCP consist of so many lines of code. Close to a million lines? Or more? Rule: Small is beautiful. That is source. The opposite s true for deployed code.
VSCP have so damn much documentation. Countless pages. Written by someone that is not naive in English. It’s a hell to read. And to understand. Rule: And page with documentation is enough. Always.
The VSCP developer never help the government to plant backdoors in the code. We all know that the big companies of course help the government when they ask for help. After all NSA is there for our security. Also for non Americans.
The bloody code is free. Free as a free bottle of beer. Rule: There is not such a thing as a free lunch.
VSCP has been continuously been developed for 16 years. Well who is crazy enough to pursue such a project. Rule: Never enter a project developed by crazy people. Especially if they are old and just one member of the team. If you join that crazy person probably know who you are and may come after you with an ax. Google, Microsoft and IBM does not even have a support email so they will never notice you enter so you are safe even if they also go as crazy and support the same system for sixteen years.
You get answers to you questions. So stupid. Often within a few hours. If you find a bug it sometimes is also fixed in a short time. Rule: Never trust a developer that respond to support requests.
VSCP never wins prices. Well of course it does not. It takes more than 15 seconds to understand what it is. Rule: Only use systems that win prices.
And a lot more. Of course there are more. VSCP is just shit. Plain shit. And will never be anything else than shit. Rule: You should not use shit.
If you decide to go for VSCP anyway, well, you are plain crazy and probably should see a doctor before it gets worse! But you should probably start here if you do.
The MQTT driver have a new parameter added from 1.1.0.22 Sodium. Previously the parameter format was
"subscribe”|”publish”;channel;host;user;password;keepalive;filter;mask
the new format is
“sessionid";"subscribe”|”publish”;channel;host;user;password;keepalive;filter;mask
where sessionid is a unique session string, That is if you have several MQTT drivers in your VSCP daemon configuration file each of them should have a unique sessionid.
I usually try to make things backward compatible but it was not logical to place the sessionid at the end in my opinion.
Cheers
/Ake