Categories
In previous versions of VSCP whenever you did an install all configuration files were replaced with the latest version. This is not true anymore. Now the new version is instead written as a copy with the date of the install appended to it. So if you after a “make install” or a “dpkg -i vscpd” want the latest configs you have to copy the backup to the actual config file and restart the VSCP server.
Files that is handled in this way is
/etc/vscp/vscpd.conf
/srv/vscp/dm.xml
/srv/vscp/simtempdata.txt
/srv/vscp/variables.xml
Also if you are on unstable code you should remove the databases before you start the updated server . Use
rm /srv/vscp/*.sqlite3
for this.
Also note that the web sample code is not installed in the install/update process no more. The process to get this subsystem installed with be described later.
The work with the upcoming 13.0.0 Aluminium release is moving on. As usual a few surprises has turned up adding some weeks to the work but things move forward as expected. Instead of being released before X-mas I now expect it to be out sometime late January next year.
For those of you doing home automation project I can recommend Domoticz and OpenHAB (in that order). Both projects has a huge and active user base constantly adding support for new devices. Much better choices for HA freaks than VSCP will ever be.
I also want to take the opportunity to wish all of you a merry X-mas. This year has been a quite rough time here and that will continue for some time but with the support from many of you I have managed to keep servers active and also had a chance to get some new hardware to play with as well. Thanks for your generosity. I will never forget.
There are a few days more coding for me before I turn of my computer and rest for a couple of days. A good book, some movies and a lot of food is waiting for me and honestly I need the rest. I hope all of you enjoy a few days rest also.
Be hungry, stay foolish
/Ake
Timers. One can wonder what they do in the decision matrix? They even have their own events defined in the CLASS2.VSCP class.
First let us define what a VSCP timer is.
A VSCP timer is a free running 32-bit timer with millisecond resolution. That is they can hold 0xffffffff = 4294967295 milliseconds which mens they will roll over in about 50 days.
There are actions defined to
There is the following internal events defined related to timers
To create and start a timer
<row enable="true" groupid="timers" >
<comment>
Create timer
</comment>
<mask priority="0"
class="0xFFFF"
type="0xFFFF"
GUID="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" />
<filter priority="0"
class="65535"
type="23"
GUID="00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F" />
<action>0x60</action>
<param>
1;10;timer1flag;true
</param>
</row>
Here a timer with id = 1 is created. The timer has an initial time set to 10 seconds. When this timer elapses it will set the variable //timer1flag// to true. The last argument is the reload flag. Here it is set to true so when the time has elapsed the initial value will be loaded again and the timer will start again.
In the example above we could have added “;4” at the end of the parameter which would have the effect that the reload would stop after four runs. Default is thus forever.
When the timer is started a CLASS2.VSCPD, Type = 25 (0x0019) Timer started event is generated. When the ten seconds has gone and the timer elapses the CLASS2.VSCPD, Type = 29 (0x001D) Timer Elapsed event is generated.
We can use either one of these two generated events to do any action periodically like this.
<row enable="true" groupid="timers" >
<comment>
Handle timer elapsed
</comment>
<mask priority="0"
class="0xFFFF"
type="0xFFFF"
GUID="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" />
<filter priority="0"
class="65535"
type="29"
GUID="00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F" />
<action>0x70</action>
<param>
/srv/vscp/timefile;1;%isoboth: Timer with id=%event.data.int32[0] elapsed %lf
</param>
</row>
<row enable="true" groupid="timers" >
<comment> Handle timer elapsed </comment>
<mask priority="0"
class="0xFFFF"
type="0xFFFF" GUID="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" />
<filter priority="0"
class="65535"
type="25" GUID="00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F" />
<action>0x70</action>
<param>
/srv/vscp/timefile;1;%isoboth: Timer with id=%event.data.int32[0] elapsed counter=%event.data.uint32[0]ms %lf </param> </row>
Here some info is just written to a file when the timer is started and when it elapses. But if you want to send an event periodically instead or do other actions this is the way to do it.
You don’t have to give a variable nor a reload flag when you start a timer. If no variable is given (use ;;) it is just ignored. The reload value will be set to false as default value, that is the timer will run only once. As the last parameter you can set the number of times the timer should reload before it should stop. The full documentation is here and here.
One useful use of timers is to handle resend of events. The working is like this
Send the event you expect a reply event from another node.
Can be used for much more of course. Just useful and simple.