Category: VSCP

Categories
CAN4VSCP Programming Python VSCP

python-can #VSCP #m2m #IoT #CAN

In a support question today I got to know the python-can package which I was not aware of. This is a package for Python developers python-can wanting to work with CAN. The package supports CANAL but unfortunately the CANAL interface is named “USB2CAN“, which disappoints me a bit,  but at least it’s there.

So all drivers here should work with Python now.

Interesting for VSCP‘ers can the remote interface of the package be. Here you can set up a lightweight connection to a CAN4VSCP bus (CAN bus) and feed it over TCP/IP to a VSCP daemon or some other thing. Perfect for use on small Linux boards where the full  VSCP daemon is too much.

Categories
VSCP

New donation

Anders Forsgren today sponsored the project with an Android phone. This will help us a lot to work on the ux.

Many thanks to you Anders.

Categories
Development VSCP

Important change to the vscpEvent/vscpEventEx structures and timestamp #VSCP

New fields in vscp event structures (vscp.h)

From version 1.12.20.0 a date/time block of the following form

        // Time block - Always UTC time
        uint16_t year; 
        uint8_t month;    // 1-12
        uint8_t day;      // 1-31
        uint8_t hour;     // 0-23
        uint8_t minute;   // 0-59
        uint8_t second;   // 0-59

has been added to the vscpEvent/vscpEventEx structures

This will affect all interfaces that read and write VSCP events. So for the TCP/IP interface which previously used

send head,class,type,obid,time-stamp,GUID,data1,data2,data3....

will now have the form

send head,class,type,obid,datetime,time-stamp,GUID,data1,data2,data3....

where datetime is the UTC date/time in ISO standard form YYYY-MM-DDTHH:MM:SS

It is possible to let the interface set this time to the current UTC time by leaving the item blank.

So

send 0,20,3,0,,,-,0,1,35

will set the current UTC time (and timestamp) in the interface when the event is received.

But on the other hand

send 0,20,3,0,"2001-11_02T17:00:01",,-,0,1,35

will use a specific date and time. Note that timestamp is set by the interface in this case.

The change affect a lot of code. Expect some instability. The helper lib has been changed appropriately so if using it your code should be safe.

timestamp

It’s a bit of  confusion before if timestamp has been set in microseconds or milliseconds.  Now this is definitely fixed at microseconds.  An unsigned long is enough to keep track of about 71 minutes before it roll over. This was considered a bit low before the date/time structure was introduced but is more than enough now.

When timestamp previously was sent with a value of zero it was set to UTC microseconds of the interface. This is not the case anymore.  Leave the field blank instead if you want the interface to set the timestamp.

Resend to the VSCP mailing list

I have previously resent blog entries here to the mailing list when I though they could be of interest for the mailing list audience.  This will be the last one resent this way. If you are interested in blog posts about VSCP subscribe to this blog. An RSS reader is another option.

Categories
VSCP

State of #VSCP (or things if you like).

I thought I ought to do a short update of how things move forward.   Well, despite me working all time I possibly can find with the new version of VSCP & Friends I still just move very slowly forward. On the positive side is of course that I write “forward” and not “backward”, but I feel things are moving very slowly ahead right now.  But it is just a lot to do and I am only one person. You bet I have wet dreams about having a team of programmers working on this.

Tables

My current work is on the new “tables” that will use a database. Reachable from all interfaces (tcp/ip, mqtt, rest, websockets) they allow for a way to collect and fetch series of measurements as the old ones did. Different this time is that Sqlite3 is used as the storage engine and that they are a lot more flexible than they where before.

The goal with tables is to be able to drag a decision matrix element in place that collect the data form a device. You have to do that manually today. And on the other end drag a live diagram/table to a web page that display the content in the table.

Anyway if all goes well I hope the full table functionality is fully in place in two weeks or so.

Discovery

Discovery is the next task. Today one can listen on the multi-cast channel for new devices that are discovered. This will be developed further so that more information about a node is published. This means that with discovery the VSCP daemon itself will go out and fetch data from nodes that it discovers. The VSCP daemon will also download and cache MDF’s.

Also new is that discovery data will be stored in a database and this data can be fetched and investigated through the different interfaces (tcp/ip, mqtt, rest, websockets).  In this database it will be possible to assign a real text name to a node and this name will in the future be possible to use when one refer to a node instead of using it’s GUID.

Lastly I hope to make a push interface to this discovery mechanism so that a VSCP aware phone for example can start an app. when a new device is discovered.

Hopefully in place before the summer. But don’t hold your breath.

Next release

The reason why I hold the next release of VSCP & Friends is that I the database structures aren’t final yet, and they will not be final until the interfacing code is in place. That is mainly the web interface code as of today, but also VSCP Works. If I release before the database structures is final I have to write update code between releases and that takes time I don’t have. So this work has to take the time it takes.

For those of you that want to try the head code, please do. But be careful to delete database files when you rebuild the project (rm /srv/vscp/*sql3).  The VSCP UX code now have a session window and variable handling and a few other functions in place and may be worth a try.

Community

It saddens me of course that VSCP has not been successful in the forming of a development community.  Today we don’t even have an active test or discussion community. This is of course harder still from a developer perspective as endless hours of work from my end just appears to end up in /dev/null.  But I still strongly feel that I will try to make the vision of a uniting system set up for soon seventeen years ago come to reality  before I give this up.  This year has been the hardest yet on this journey. and without all your kind donations I would not have been able to proceed at all. Thanks!

If someone out there share this passion or a tiny little tiny bit  of it, take on some VSCP work.  Web ux interface and bindings to different languages is probably the most important tasks at hand.  But there are so much more.

Have fun!
/Ake

Categories
VSCP

The #VSCP sync

Sync

To ask for readings (measurements/sensor values) from nodes one can use CLASS1.CONTROL, Sync. One can use sensor index, zone, subzone as a way to tell which readings are of interest. A node should send the requested value immediately when it get a sync. For cashing, use tables or variables to store the readings.

The sync’s primary use is to synchronize sensor readings from multiple nodes in time but it can obviously also be used  just to request data.

You can see that modules from Grodans Paradis AB implement the sync but also have registers the data can be read from and automatically repetitive delivery of sensor data.

For the Kelvin 1-Wire module for example the sync has the following description

If a SYNC event is received by the module it will check the zone/subzone parameters of the event and send out temperature measurement event(s) for all sensors that match. This can be a handy feature to use of one want synchronized data from several sources.

But you can also instruct the module to output temperature sensor data with a set time interval (see report interval registers here) or read the temperature reading in a register (see temperature registers here).

Periodical events are perfect when the VSCP daemon is part of a system. Tables and remote variables is two features it have that is well suited for this type of sensor data.

Tables is being rewritten and extended from the functionality available in the last release at the moment and is mostly into place in the head code right now. There is a description here. One can do many things with sensor data in them and actually create user defined SQL databases if one like that which can have its data requested over REST/TCP/IP/websockets…

If one want the x last readings the static table is perfect as it works in a round robin fashion.

One can also use remote variables to store certain sensor data. In many of my setups I use them all the time. A typical sample is a sensor value that should be sent on specific intervals to a cloud service but where internal systems need this sensor value at a much higher rate than the cloud service need it. The easiest way to do this is to store the value in a variable with a DM entry when it is received. This way one have the sensor value accessible all the time and  request the latest value over any of the interfaces. To send the value to a cloud service one use one of the internal events for example the minute event and send the value there calling an external script or using one of the internal actions such as the http put/get/post action or even the run internal JavaScript action (soon LUA to).

Well that’s power for you!

Categories
VSCP

The #VSCP GUID (Globally unique identifier)

GUID’s

A GUID is the one and only id for all VSCP devices, It is globally unique, 16-byte, and will never change. It can be derived from some common id’s like MAC addresses or come from a user/company assigned “namespace” which can be requested for free.

At the application level this is the id “that should” be used if one want to have an id that absolutely does not change over the life of a device.

The problem with 16-byte id’s is obvious and specially clear on CAN devices. There is no room for it in the payload. One see this in wireless payloads also. VSCP therefore uses “nicknames” for devices to identify a unit on a local segment/bus. A nickname is a number (any) that directly translate to a GUID. For CAN this nickname is a 8-bit number that is not zero (reserved for a possible master) and not 0xff (reserved for an uninitialized node).

On CAN a nickname can be assigned using the automated nickname discovery or be hard assigned. In the case of nickname discovery a possible master is search first and if there this device is supposed to assign a node id to the node. This is NOT implemented in the VSCP daemon (but may be) and must be handled in user land. That is one listen for CLASS1.PROTOCOL, New node online/probe to node zero and respond to it if it is detected and after that assign a nickname.

The nickname will normally not change on a bus. And one can make sure it does not by assigning the old nickname to a node that for example is replaced. But it can not be guaranteed so it is better to use zone/subzone’s as a way to connect “groups” together. That way when a node is replaced one only need to load it’s registers with the original nodes content and it is a replacement that is a real copy of the old device.

So at this point one have a one to one mapping between the GUID of the node stored in standard registers 0xD0-0xDF an the nickname. A table than must be added to/changed when a CLASS1.PROTOCOL, New node online/probe comes in by reading the GUID of that node.

One can easily do a REST i/f <-> CAN4VSCP interface app here if one want that. For example is a uvscpd planed that only have a driver interface and a link to a tcp/ip interface on a remote VSCP daemon.

Back to the uniqueness of the GUID. The VSCP daemon confuses things. This is because the fact that VSCP actually only identify things with VSCP GUID’s. So a Level I driver that implements the CANAL interface will receive and send using nicknames on the lower part but will use gull GUID’s on the higher part. This means that a device with GUID-A pass an interface (VSCP Level I in this case) and the will look as if it comes from GUID-B. Well one also send events to GUID-B.

The thing here s that the interface also is identified by a GUID. Either server assigned or user assigned. This is true for all interfaces on the VSCP daemon. It is important to note that this GUID can change when a daemon is restarted because the interface becomes another one.

Interface GUID’s of the VSCP daemon is built like this

XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb

0xaaaa form a server assigned id for the interface. 0xbbbb form the nickname and is actually 00bb for a Level I driver where bb is the nickname.

So for a user sitting on the REST/TCP/IP/websocket/mqtt interface a node that has a GUID YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY may look like it is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb. The only way to know the real GUID of a node is to read its GUID with CLASS1.PROTOCOL, Extended read register for example.

Again it is a one to one relationship and a CLASS1.PROTOCOL, New Node online from that interface may changed things so the table needs to be updated.

Not hard to implement on the application level.

That said the next version of VSCP & Friends will have a new function called node discovery. This is partly in place today also as new nodes are announced on the VSCP multicast channel. But this will be extended so nodes can have a unique name instead of the GUID and also the daemon will keep an internal table of “real GUID’s” one can query. Also MDF’s will be cashed by the server.  This is what I will take on next after the new tables functionality I work on now is finished. Hopefully released before the summer.

In the meanwhile if one assign a GUID to a driver. And make sure that nodes use the same id, that is is initialized only once, the interface GUID is fine as a node identifier if one skip the 0xaaaa interface part of

XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb

and just compare the rest. Also the one to one relationship works then to the “real GUID”.

VSCP and unique id’s.

A node’s assigned nickname id will be retained after a reboot on a CAN4VSCP bus device (or should). It is only changed (or can be) if the configure buttons is pressed. The first free id will be used in the nickname discovery process. In practice I see that this always turn out to be the same id in a real system but if one has removed other nodes in between one can never be certain. But it still is not a big problem for a service person. He/she in the first place press the configure button so it should not be a big problem to check that the id turned out to be the same and manually change it if not. The only time the configuration is done is during install and replacement of a node anyway. Another schema than the nickname discovery is to preferred for nodes that are going in and out on a CAV4VSCP bus.

 

Categories
General VSCP

#ESP32 About the CAN controller. #IoT #m2m #VSCP

The perfect VSCP companion.

Source: About the CAN controller. – ESP32 Forum

Categories
CAN4VSCP Bejing CAN4VSCP Kelvin NTC10KA HowTo's

Refrigerator project Part 4 #IoT #m2m #VSCP

This (upper cabinet of refrigerator)

and this (lower cabinet of refrigerator)

 

is live data from the refrigerator project described here,  here and here.

First of all, this is quite a complex way to do this, it could have been solved in an easier way. But I wanted to test the modules Grodans Paradis AB made and put them to work.

Two CAN4VSCP based modules has been use for this project. The Kelvin NTC10K module is used to sense temperatures and the Beijing I/O module is  used to turn /on/off the compressor.

Configuration

Kelvin NTC10K

The module is fully describe here.

The Kelvin NTC10K (on nickname = 5) have one thermistor connected to input one which is located in the upper cabinet of the refrigerator and the one thermistor connected to input two which is connected to a sensor that is located in the lower cabinet.  Both has been set to send out temperature every ten seconds

As noted also the on-board sensor send out temperature data, It sends out the data with a longer interval (0x3C = 60) which is once a minute.  This value can be used to sense the room temperature but is always a bit high as the sensor is placed on the pcb. One can adjust this in the sensor calibration registers

Most thermistor needs a calibration and here it can be set with a two complement number that can calibrate a temperature with an accuracy of  two decimals.

If you want temperatures sent to some sort of central server this is actually all you need to configure.  The values will be sent with the set interval. The default unit is degrees Celsius but this can be changed. In our case we also need some other features enabled. This configuration we do in the control registers for each sensor

Temperature Sensor 0 and temperature sensor 2 just send out the temperature with the set interval. They are set to 1 which means they send the temperature in degrees Celsius.

For temperature sensor 1 more features has been enabled. It is configured with 0xB9 which is 10111001 in binary.

As Bit 0/Bit 1 forms 1 the temperature will be presented in degrees Celsius as for the other sensors.

Bit 3 is set so low alarm is enables.

Bit 4 is set so high alarm is enabled.

Bit 5 is set which means that CLASS1.CONTROL, TurnOff events and CLASS1.CONTROL, TurnOn events will be sent instead off CLASS1.ALARM,  Alarm occurred. So an OFF event will be sent when the temperature goes below the low alarm level and an ON event will be sent then the temperature goes above the high alarm level.

Bit 7 is set which means alarm events will be sent continuously, not just when a limit is passed.

For this to work we need to set the low alarm level

which is set to four degrees Celsius. And also the high alarm value

which is set to six degrees.

The hysteresis value is set to two as default and we leave it at that.

So what will happen here?

If the temperature is below four degrees Celsius CLASS1.CONTROL, TurnOff events will be sent out every second. This will continue until the temperature is above the low alarm temperature + the hysteresis, that means at 6 degrees.  When the temperature go over 6 degrees Celsius CLASS1.CONTROL, TurnOn events will be sent out every second until the temperature goes below the set high alarm point minus hysteresis, that means 4 degrees Celsius.

In addition to the TurnOn/TurnOff events the temperatures will also be sent out for us to diagram or collect in a database or do other things with.

Before we setup the Beijing module to handle the TurnOn/TurnOff events we need to mark out TurnOn/TurnOff events so they can be identified to the refrigerator. We can do this with the nickname id (node id) which in this case is set to 5. But this value could be changed if a module is replaced but it can also be good not to use this id for other purposes as well.  So instead we use the zone/subzone. For the Kelvin NTC10K we can set a zone/subzone for each sensor.  And we set

the zone to hex 23 (35 decimal) and the subzone for each temperature sensor to it’s index. So temperature sensor 0 get subzone= 0, sensor 1 get subzone=1 and so on.

There is no magic here. One can set up any number schema one likes.

This is how a temperature event looks like for sensor 1

And this is how a CLASS1.CONTROL, TurnOn event  looks like

Beijing I/O module

The module is fully described here.

The Beijing module can do many things. But as we have a relay that control the compressor of the refrigerator connected to I/O channel we are only interested in configuration of this channel.

The I/O channels of the Beijing module is set as outputs by defaults

We have set bit 1 as an input here for a task we want to go through in this write-up (refrigerator door sensor).

Note also that the nickname (node id) is set to 4.

We also need to match the zone with the one we set for the Kelvin NTC10K (0x23) and also the subzone (0x01) for I/O channel 0 .

That is all we need to configure.

To complete the  task we also need to program the decision matrix of the Beijing module. In this matrix we program what the Beijing should do when certain events is received by the module.

In our case there is the two events from the Kelvin NTC 10K module we are interested in.

If CLASS1.CONTROL, TurnOn is received we want I/O to be turned on or stay on, that is the compressor of the refrigerator should be turned on.

If CLASS1.CONTROL, TurnOff is received we want I/O zero to be turned off or stay off, that is the compressor of the refrigerator should be turned off.

The decision matrix have actions it can perform when an event matches a selection criteria. For us the SET and CLR actions is what we need.

The rest of the actions are described here.

We program the decision matrix like this. One row for each action we want to be carried out

In the first row, which looks like this

we enable the row,  don’t check the originating address as we discussed above, and the originating address is not hardcoded, the zone of the received event should match the zone of the our module (0x23) and the subzone should match that for the channel set in the action parameter (I/O 0 = 0) or the module subzone depending on chosen action.

the class mask tells which bits of the class filter that is of interest. Here all is of interest (0x1FF) and the class filter is set to 0x1E which is 30 and is the code for CLASS1.CONTROL

The type mask tells which bits of the type filter is of interest. Here all is of interest (0xFF) and the type is set to 0x05 which is the code for CLASS1.CONTROL, TurnOn

So if a CLASS1.CONTROL, TurnOn event is received with zone=0x23 and subzone=0x01 the Beijing module will carry out the chosen action. We want I/O 0 to be turned on so the compressor is turned on and the action set output of I/O channel high will do that for us.  This action expects the I/O channel as action parameter so we set it to x00.

So now out CLASS1.CONTROL, TurnON events will turn on the compressor.  The Beijing will confirm the I/O change with a CLASS1.INFORMATION, On event.

The DM row for the CLASS1.CONTROL, TurnOff is then setup in  the same way.

Thats it. We have now made a self contained unit consisting of two modules that can work autonomously.

The cloud

The  fridge project explains how to share the generated data to the cloud.  I will do another write-up about this later. But it’s not more to it then to program the decision matrix of the VSCP daemon to send data to the cloud.  You have live data for this setup here as a sample. This data is on a CAN4VSCP bus in this house and is collected by a Raspberry Pi and is sent up to ThingsSpeak.

VSCP have other means of displaying data and more will come in the next version.

 

Categories
CAN4VSCP Bejing CAN4VSCP Kelvin NTC10KA CAN4VSCP Paris HowTo's VSCP

Refrigerator control Part 3 #VSCP #IoT #m2m

The refrigerator again. It takes more time then expected of course. It always do. This time because I have a lot of other things to attend to at the moment.  I understand if you ask some questions about this project. So I answer them here (before you actually ask them)

Why this project?

Our refrigerator broke down two weeks ago. And we need one also in my family.  Of course we do, open source programmers may not afford much buying stuff but we also want our milk to be cold.  Luckily it is winter here now and we have some other storage that is at about four/five degrees so it is no immediate panic,  but as weather is getting better (the spring is coming)  this is not a good long-term solution.

When our fridge broke down some years ago I decided to try to rescue it and if it was possible I would take standard VSCP modules to do so.  The compressor was OK and if it is this is a simple  project mostly.  This project has worked perfectly well since then and became a nice VSCP demo project.

Yes, Yes, YES it’s an overkill using VSCP standard modules for this. An Arduino or some other simple board would have done the job. But I wanted to use the modules to see if they did their job also over time. The best way to actually see if things are working the way you thought is to put them in some critical system in your house (the heating in our house is already controlled this way). If there is some bugs or design problems things will be solved by necessity. To have them in a demo system on a workbench is just not the same thing.

So for the refrigerator the first question was to check if the compressor still worked. If it was dead it is just a pieces of junk and not a refrigerator.  But just as with the fridge it was the control logic that had broken also this time. Make me wonder how many perfectly fine refrigerators/fridges are thrown away out there that could have new  control added for a few bucks and do the job they were designed for for many years more.

How?

As with the fridge I decided to go for standard VSCP modules for the refrigerator project to make it a demo project.  It is easier this time as I have the CAN4VSCP bus connected to the fridge that stands next to the refrigerator. I just need to connect the two together.

So I put in a Kelvin NTC10K module and a Bejing I/O module in the refrigerator and hook it up to the CAN4VSCP bus so I am able to monitor temperatures and change temperature settings and get possible alarms from the unit.  As with all VSCP modules they form a self-contained unit.  There is actually no need for a server after they have been configured. The second video here show the configuration process and the first show how the modules are connected together.

The Kelvin NTC 10K module is a module that one can connect a couple of temperature sensors to.  It can be programmed to alarm at low and high temperatures and as in this case turn on and off things when certain temperature thresholds are reached.

In the fridge project a Paris module is used together with the Kelvin NTC module. The Paris module is constructed to control relays and have all the electronics on board to do that. It also include protection timers and a lot more.

In the refrigerator project I decided to use the Beijing module instead of the Paris module. Mostly because it did not matter to have standard I/O channels  as I use a solid state relay to switch on and off the compressor, but my main reason was that  I got a chance to use it in a real life demo system.

So the Kelvin NTC10K module sense the temperature in the refrigerator and the Beijing module is used to switch the compressor on or off and to sense if the refrigerator door is open or not and if it is light the lamp inside the box.

It is possible to  sound s siren if the door to the refrigerator is opened between midnight and six in the morning. But some things just hit you right in the face so I will not implement that functionality. At least not now.

Next?

Connect cables and putting it in the refrigerator where the old control logic was located. No programming is needed just configuration.  The second video above show a bit of this configuration but I will go through it in a more precise way in a future post. Hopefully things will work as thy should tomorrow. The VCSP modules are very flexible and can be used in most control situations to form self-contained systems that can be connected together and be connected to the world in a safe and secure way.

Categories
HowTo's VSCP

VSCP module setup – Refrigerator control project

Part 1

Demos VSCPWorks

Part 2