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.
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.
One day the fridge in our house died. Probably due to a recent thunderstorm. Panic of course and when I noticed that it was totally dead I bought a new one and saved the situation. The fridge was left in its location and later I realized that the control logic inside it was dead. I checked the obvious things but without a drawing it was not much I could do and buying a new board was in excess of EUR 250 so I decided to build my own control logic.
Well, I as most people, have a lot to do, so two years later I actually started the project. As my company build VSCP based modules I decided to use two of them for the project and by that way make it a reference project. I could have done this much easier probably with an Arduino or similar, after all it’s not a very complicated project, as a fridge is an easy thing to control. It is just basically turn on compressor when it’s to hot inside it and turn it off when the wanted temperature has been reached.
But as I said above my company makes control modules and I am the maintainer of the VSCP project so this could be a reference project for VSCP and our modules. That and to again to get a working fridge in the kitchen therefore became the goal of the project.
So that was the staring point. Join the journey.
Old control card
This picture shows the controller card after I removed it. A beeper, a transformer, a potentometer for the set temp, a boost button and some LEDs is all that it is.
As I am rather feed up with changing batteries in units all the time i prefer cables when ever possible. Therefore I decided to draw wires from my office up to the kitchen. I wanted an RJ-45 connector there anyway for Ethernet so I draw CAT-5 cables for that one, and another CAT-5 for the CAN4VSCP bus. Yes I could have used Ethernet for the fridge also of course. But I decided to use CAN4VSCP for demo/test purposes and because it have the advantage of having power included.
Office at the bottom floor and apartment at the top floor. in this old school house.
I live in an old school house (well this picture is old to) so putting in new cables is not a big deal. Just to make more holes in the walls and add more cables. It still is some work of course drilling in 30 cm solid wood walls but as I see it worth the effort it in the end and being an embedded programmer I need the exercise anyway.
Two modules from my company was the perfect choice for this job. The Paris relay controller that can control seven relays and the Kelvin NTC10K that can read six temperatures. Well it’s just one relay to control in this case and the relay I decided to use is a solid state relay that could have been used without the extra driving capabilities of the Paris module but it is really the functionality of the Paris module I am after. Same is true for the Kelvin NTC module. I don’t need the extra temperature measurements this module can offer but as it had the capabilities I decided to put a temperature sensor on the compressor of the fridge to check it for overheating as well and another sensor in the kitchen itself. It is also easy to connect more sensors if/when the need arise.
Testing the modules before mounting them.The Paris relay module to the left and the Kelvin NTC10K to the right with one NTC sensor connected.
All CAN4VSCP modules can be connected together (and be power) over the RJ-45 connector or over the daisy chain connector on the board. In a cabinet the daisy chaining is perfect and convinient. Here the CAN4VSCP cable is drawn from the office which is downstairs in our house. This cable also supply 24V power to the modules and is UPS protected at the source. The modules then are connected together using the daisy chain connector. For more boards one can use the CAN4VSCP power injector but that was not needed in this case with just two modules.
Paris in place and Kelvin NTC10K waiting to be mounted in the control logic part of the fridge.
Next step is t mount the boards in the control logic enclosure where the old control card where installed. I had to remove some plastic fittings for the old board but after that evrything was easy to mount.
Paris firmly mounted with the wall type mounting accessories for CAN4VSCP modules.
The boards my company sells have two mount options. Screw/wall mount or DIN rail mount. In this case I use the screw mount versions.
LED’s and solid state relay
Then it is time to mount the solid state really and some LED’s for status information. The LED’s show that the fridge is on, compressor status and a warning LED for low temperature. The solid state relay is a standard 230V/10A five volt controllable piece. Pretty standard gear.
LED’s, solid state relay and wall mounts for the two CAN4VSCP modules.
Then it was time to connect things together
Connecting things together
and mounting it all on the fridge
Time to drill a hole for the new fridge temperature sensor and mount it remembering to isolate well. The old sensor was mounted with some plastic stuff and I used it for the new one as well.
Then put back the plastic covers of the fridge and put it back in it’s place. Powering it. Yes dead so far. The boards has had not been configured yet so that was just what I expected. To be honest I would have need disappointed if the fridge started to work at this stage.
Drilling drilling drilling, cables, cables, cables till it all is down at the office.
A wall in the office used as test site.
So time to set things up down at the office. A power supply of course. 24V and connected to an UPS so things will work also if the power fails. Two CAN4VSCP modules and a Raspberry Pi is also mounter here on the DIN rail. As you see I expect more modules to be installed here later as the demo project goes on with other parts.
The modules I install here is another Paris relay controller module which I need for some light control. More about that in a later post.
The other module is Frankfurt RS-232 module which connects with the USB to serial converter that comes with it to a Raspberry Pi.
Note that the Raspberry Pi is powered from one of the CAN4VSCP modules. Plenty of juice for that in a CAN4VSCP module.
Software and configuration
On the Raspberry Pi is the VSCP Daemon installed. Instructions for setting it up on the Raspberry Pi is here. I use a read only file system to make things stable as documented on the linked page. The risk one face otherwise is a corrupted SD card when power fails which happens also when an UPS is used as in this case when disconnecting cables etc. I can really recommend that approach.
The Raspberry Pi is just used as a link between the CAN4VSCP bus and TCP/IP. But as documented later in this document it does some other work to. When the Frankfurt Eth board is available I will probably replace both the Raspberry Pi and the Frankfurt RS-232 with it. Time will tell.
From the config string we can see that /dev/ttyUSB0 is the port used. This is what was assigned or the USB serial adapter. Use
to list available adapters. Normally the Frankfurt RS-232 adapter communicate using 11520 baud but the 5 in the configuration string tells that we here use 500000 baud in this setup. Speed is good.
The path to the driver is the standard place on a Linux box after installation of VSCP & Friends.
The flags value of 32 may need an explanation. This is a bit array so it may be easier to see it in binary form which is 0b00100000. That is bit 5 is set. Looking at the driver documentation CAN4VSCP driver we see that this means that hardware handshake should be enabled.
So nothing strange really. All we need to do to get things working is to restart the VSCP daemon with
whih will connect things to the world or to our local net.
But before doing that we can use the diagnostic feature of the Frankfurt RS-232 and see if we can see all modules on the bus. We can do this by using a terminal program on the Raspberry Pi. I use minicom (sudo apt-get install minicom) for my needs. Starting it with
minicom -b115200 -D/dev/ttyUSB0
will connect to the Frankfurt RS-232. If we issue
the connection to the CAN4VSCP bus will open. Issue
to scan for available devices on the CAN4VSCP bus. In my case I got
I can see that I have the Kelvin NTC10K module at nickname = 1 and two Paris relay modules at nickname =2 and nickname = 3. The question is which module is which of the two Paris modules. The easiest way to determine this is to push the init. button on one of the devices which will make it go through the nickname discovery process and at the end show it’s discovered nickname. I used that method and found the the node with nickname=3 is the one installed in the fridge and the one with nickname=2 is the one installed in the office. I can change this of course but it really did not matter in this case.
A reader that is on his/hers toes notice that the GUID’s for two nodes are set to all FF’s which is wrong and not unique at all. I had to fix that at this stage. The reason was that I use nodes that are left overs from production and a GUID had never been set on these modules.
Knowing that the nodes are reachable and working makes things easier (and me happier). I restarted the VSCP daemon on the Raspberry Pi and could then do the rest of the configuration work on my desktop computer over TCP/IP and using VSCP works.
To setup VSCP for this task is easy. Use any Windows or Linux computer. I use Linux in this sample as that is my main working system.
Using VSCP Works t he first one has to do is to configure how we want to talk to the devices. There is two possible ways to do this. One is to talk directly to the driver. This means it must be connected to the computer on which you are located. So if we had the Frankfurt RS-232 connected to this computer we could have configured the CAN4VSCP driver in VSCP Works to connect to it and to the CAN4VSCP bus.
In this case the Frankfurt RS-232 is connected to a VSCP daemon on a remote device and this is the other way we can connect to it. So ee connect to it over TCP/IP and via the VSCP daemon on the Raspberry Pi. This works if the remote device is in another room as in my office or equally well if it where located on the other side of the earth. SSL is available for protection.
The configuration looks like this in VSCP Works
Basically the settings is the name we want to give this connection. The ip-address of the daemon and the port which usually is the VSCP assigned one (9598). Username and password and interface name. The interface name is important. You select it by choosing one of the available interfaces from the list you get when you click on the “Get Interface” button. This tells which interface you want to talk to on the remote daemon. After this is done you can connect to this location with all the tools available in VSCP Works.
The interface is important because we use nickname to talk to devices on a bus when usinge VSCP Level I. Many interfaces can be conected on a VSCP daemon and therefore the same nicknames will be present on multiple interfaces. In VSCP Level II where the full GUID is used this is no problem of course.
I can now use the configuration interface of VSCP Works and set register 3 to one. This will start the compressor of the fridge. And it did so it works. But we need to automate this. Making an autonomous system of it. This is one of the great advantages of VSCP. The possibility to leave out a central computer and by that a central point of failure. When things are configured a group of modules just work.
Configuring the Kelvin NTC10K
As the Paris relay module is dependent on the Kelvin NTC10K module for it’s work it was best to start to configure this module.
We want this module to send out temperature values with a certain interval so we can log temperature data. We also want it to send CLASS1.CONTROL, TurnOn events when the temperature is higher than a l high set point and CLASS1.CONTROL,TurnOff events when the temperature in the fridge is lower than a low set point.
Temperature sensors are connected like this
Sensor 0: On board temperature.
Sensor 1: Fridge temperature.
Sensor 2: Compressor temperature.
Sensor 3: Currently not used.
Sensor 4: Temperature in kitchen.
Sensor 5: Currently not used.
The compressor temperature should be reported with 10 second intervals. So we configure that by setting register 0x16 to 10 (0x0A). That is all we need to do for that sensor.
We do the same for the kitchen room temperature by writing 10 to register 0x18 so it also is reported every ten seconds.
And then we do the same thing for the fridge temperature by setting register 0x15 to 10.
This is all we have to do to get a system that report temperatures every ten seconds. In the picture above we see the sensor value for the fridge (-20.86 degrees Celsius). We can change the unit to Fahrenheit or Kelvin if we prefer that instead of the default degrees Celsius. For a logging system this is all we need to configure.
But this system should do more and for sensor 1, the fridge temperature sensor, we need to configure some more registers to get the functionality we wanted as of above.
We get the requested functionality by writing 0xB9 to register 3 which is the control register for sensor 1. 0xB9 is 0b10111001 in binary. An the functionality we set is
0b10111001 – Bit 0/1 – Report temperature in degrees Celsius.
0b10111001 – Bit 2 – Reserved not used.
0b10111001 – Bit 3 – Enable low alarm.
0b10111001 – Bit 4 – Enable high alarm.
0b10111001 – Bit 5 – Send TurnOn/TurnOff events instead of alarm.
0b10111001 – Bit 6 – Don’t invert meaning,
0b10111001 – Bit 7 – Continuous alarm.
The enable of alarms (Bit 3/4) makes it possible to get alarms when temperature goes over or below set points. Normally an alarm event is sent out and alarm bits set in the alarm register. It is however possible to get TurnOn/TurnOff events sent out instead at the alarm points. This is configured by setting Bit 5 to one.
Last Bit 7 is set to one which makes the alarm or in this case TurnOn/TurnOff being repeated very second as long as the condition is valid. This can be good to use as a precaution for communication errors.
There is no need with alarm points without setting them so we set the low alarm point by writing 0xff to register 0x34 and 0xFB to register 0x35 which is the 16-bit register for the low alarm point in degrees. This is equal to -21 degrees Celsius which is the lowest temperature we want the fridge to have.
We also write the high alarm point by writing 0xFF to register 0x40 and 0xED to register 0x41. This is equal to -19 degrees which then is the highest temperature we accept.
We should note here also that there is a hysteresis value for alarms that default to two degrees. That is an alarm condition is valid until the temperature goes either above the low set point with that amount or below the high set point with that amount. This is why the low and the high temperature set points are two degrees apart. It is possible to set them further apart but always equal to more the the configures hysteresis.
So what have we accomplished here now?
If the temperature is higher than -21 degrees Celsius continuous TurnOn events (one very second) will be sent out until the temperature has reached -21 degrees Celsius.
When the temperature goes below -21 degrees Celsius continuous TurnOff events (one every second) will be sent our until it goes up to -19 degrees Celsius.
We get temperature events sent out every ten seconds telling the actual temperature for three sensors.
Before we start to configure the Paris relay module we need to configure one more thing.
When events are sent all of them except CLASS1.PROTOCOL is sent without a destination address. The receiver decides if it is interested in the event or not. As a means of grouping things together zones and subzones can be used. They are both 8-bit identifiers that define a zone and a subzone within that zone. Its good to set up a schema for a specific setup and here in my house I use the following
The zone is divided into two 4-bit parts. The high part is the floor plane. 0=cellar, 1=office, 2=Apartment, 3=Attic, 4=Garage…
The rooms is then coded into the lower four bits of the zone.
A zone=255 always mean all zones.
Subzone is used for specific group of things in a room that needs to be grouped or be identified. A sunzone=255 always mean all subzones.
So the fridge, which is at in the apartment, the zone is 0x22 as the kitchen is coded as 2 and the fridges s set to subzone=1.
So we program that in for the sensors as well. Register 0x4D holds the zone for sensor 1 and register 9x4D holds the subzone. We use the same setting for the other sensors as well but it really only matters at this point for sensor 1.
We used the default NTC 10K sensor with this setup so the B value for the sensors are already set. If we have used another sensor we needed to code this value for all sensors as well. For best precision we also could have programmed a calibration value but a fault of about one degree is OK in this setup. Information about all Kelvin NTC10K registers is available in the manual.
Configuring the Paris relay module
The Paris module has one task to perform. It should turn on the relay when told to do so and turn it of when told to do that. Simple enough. With a server in the system it could have written a one in register 3 of the module to turn on the compressor when the temperature was to high and turn it of by writing a zero into register 3 when the set temp is reached. But we want this to work in an autonomous way without a server so we need to set this up.
We again start with the control register for relay 1 which is connected to the solid state relay which driver the compressor. This is register 0x0B and the default value is actually OK here so it is no need to change it but we go through the bits and there meaning anyway. The full Paris relay controller manual is here.
The programmed byte is 0x98 which in binary is 0b10011000 and have the following meaning.
0b10011000Bit 0 – Set to zero no pulse output activated.
0b10011000 Bit 1 – Set to zero so no alarm. The protection timer is not used anyway in this sample.
0b10011000 Bit 2 – Set to zero meaning protection timer is disabled. This timer can be used to automatically turn of a relay after a configurable time and optionally send an alarm when doing so.
0b10011000 Bit 7 – Set to one which enables functionality.
The only interesting for us here is that we get confirmation events when relays are activated/deactivated.
We set zone/subzone info here also just as we did for the Kelvin NTC10K. Again we use zone=0x22 and subzone=1 which groups the two modules together, saying this is events belonging to the fridge in the kitchen on the apartment floor.
But still nothing happens. The Paris relay module will just disregard the TurnOn/TurnOff events sent out from the Kelvin NTC 10K.
The solution is to program the Decision Matrix (DM) of the Paris module. This matrix is a event-decision-action matrix. That is when an event is received, a decision is made if it is useful and if so a specified action is performed. Every VSCP module with a DM implemented have a series of well defined actions specified. So what we need to do is to program what should happen when the TurnOn event is received from the Kelvin NTC10K module and likewise what should happen when the TurnOff event is received.
In this case the task is straight forward.
TurnOn received: We need to activate the relay.
TurnOff received: We need to deactivate the relay.
The tool to use is as always VSCP Works and the configuration view and the Decision Matrix tab. Double clicking a row here makes it possible to edit the row
The first row is used to turn on the relay. We specify that the zone and the subzone should be the same as we programmed for both of the modules (zone=22/subzone=1) by selecting that zone and subzone should be checked. In the class mask and filter we set the class mask to 0xff meaning all bits of the class filter are valid. Then we set the class id for the TurnOn event into class filter which is 0x1E. This means that when a CLASS1.CONTROL(x1E), Type=TurnOn(0x05) event with zone=0x22 and subzone 0x01 is received the action we choose here will be performed. In this case we want it to activate relay one which is the second relay channel, that is bit 2. So we select “Activate relay(s)” for action and put 0x02 as action parameter meaning relay 1 (bit 1 is set) using zero offset.
That’s it. We have now created our autonomous fridge control.
In the above picture we see how things looks like in the working system when the temperature inside the fridge is below -21 degrees Celsius. The Kelvin NTC 10K send the TurnOn event every second and the Paris relay node replies with an ON-event for all of them indicating it has done the requested relay activation. Most of the time the relay is already on but if it was not it would have been turned on. With ten second intervals temperature events for the sensor are sent and highlighted here is the fridge sensor which is at this point is about -20 degrees Celsius.
This picture show the events when the temperature has been reached. And this is therefore the message stream that will be visible until the high set point has been reached. Here TurnOff events are sent every second from the Kelvin NTC10K module and the Paris relay module respond with an OFF event when the relays has been turned off or is already off.
Extensions is alarms such as sounding an alarm when the fridge temperature goes above a certain value and/or sending an SMS informing of the condition. I will come back to these extensions later in another post.
If you want to look at the register content or copy it to your own modules the register files for the sample are here
The easiest way to view the files is to open an empty configuration session and load the file there.
It may be useful to log data into a database or similar for later use. Here I use a MySQL database located in the cloud for this purpose. It can be a local database equally well of course.
One way to do this is to use the VSCP helper lib with your favourite programming language and write some code that performs this. It is usually just a few lines of code for a simple task like this.
Another way is to use the capabilities of the internal decision matrix of the VSCP daemon. This is a more powerful decision matrix than the simple one that is available on low end VSCP modules. It however works mostly the same as every event received by the VSCP daemon is feed through this matrix and is able to perform an action when it matches some criteria.
The decision matrix of the VSCP daemon can be edited in the configuration file/dm.xml file which resides in /srv/vscp on Linux (ProgramData\vscp on windows) or it can be edited in the web interface of the VSCP daemon which is at http://ip-address:8080/vscp. The web interface is the easiest way to use IMO. If you edit the dm.xml file directly remember to restart the VSCP daemon so that the new file is read.
This is how the DM row look like to log data to an external MySQL database with a database structure defined as below
The action used in this case is 0x10 which executes an external program on the machine where the VSCP Daemon is installed.
In the web interface the DM list looks like this
If we click on this we get the content for this DM row
If we walk through the parts of it
groupid – This is any textual id you want to use to group a number of rows together. It is mainly intended for use by external applications that work with the DM.
priority – Let you set a specific priority you are interested in. The left part is the priority and the right part (blue) is the mask. The mask tells what bits in the left column that is of interest. Set to zero (default) if non is interesting or 0xFF if all is interesting. Here we do not care about the priority and therefore set the mask to zero meaning events with all priorities will trigger this row condition.
class we recognize from the DM in the decision matrix of the modules. Again the left part is the class and the right part (blue) is the mask. The main difference here is that the class is a 16-bit number. If you are interested in events of a specific class enter the class in the left field and set the mask to 0xFFFF (default). If you are interested in events of all classes set the mask to zero (don’t care). Here we are only interested in CLASS1.MEASUREMENT which is coded as 10.
type we also recognize from the DM of the lower end modules. Again it is 16-bit here. If you are interested in events of a specific type enter the type in the left field and set the mask to 0xFFFF (default). If you are interested in events of all types set the mask to zero (don’t care). Here we are only interested in CLASS1.MEASUREMENT, Type=6, Temperaturewhich is coded as 6.
GUID – The nickname we saw earlier is just that, a nickname for a full GUID. The nickname is there to save bandwidth so the full GUID does not have to be used. Every node have a GUID and also every interface of the VSCP daemon gor one. In the case of an interface the nickname will be repeated in the LSB byte of the GUID and we see here that the GUID LSB is set to 1 which was the nickname for our Kelvin NTC 10K node and the corresponding mask is set to 0xFF with all other bytes set to zero. So all events from modules with nickname = 1 will be fulfilling this requirement. This is OK as we just have one interface on the test machine but we would have needed to check more bytes of the GUID in a real world scenario where there was more interfaces used.
Index – Here we can check for the content of the first data byte of an event or check the measurement sensor index. In this case we don’t need this check. Corresponding control checkbox must be checked for the check to be performed.
Zone – Here we can accept only events with zone set to a specific value. We don’t use this in this example. Corresponding control checkbox must be checked for the check to be performed.
Subzone – Here we can accept only events with subzone set to a specific value. We don’t use this in this example. Corresponding control checkbox must be checked for the check to be performed.
Control checkboxes – You can enable the DM row here, you can tell the parsing mechanism that this is the last row that should be checked which can be good for certain debugging. You can also enable check index, check zone and check subzone here. If check index is checked together with the “Use measurement index” to the right of the index input field the measurement index is used for the compare instead of the index byte (byte 0) of the data.
Allowed from – is the time from which the action is allowed to occur. The format is YY-MM-DD HH:MM:SS. In the web interface ‘*’ can be entered to mean “beginning of time” or any date far back in time.
Allowed to – This is the end time up to which the action is allowed to occur. The format is YY-MM-DD HH:MM:SS. In the web interface ‘*’ can be entered to mean “end of time” or any date far in the future.
Allowed Time – This makes it possible to make actions happen every ten minutes etc etc. See the documentation for full info. All times is *-*-* *:*:* As an example *-*-* *:*:0/10/20/30/40/50 will allow he action to occur every ten seconds.
Allowed day – Days when the action is allowed to occur. Here every day.
Action – Is the action to perform. There are many available. See the documentation. Here we execute an external program.
Action Parameter – What is entered in this fields depends on the chosen action. For execute external program the command to execute and parameters for that command is entered. Here we call the mysql client.
Comment – Here a comment about the DM row can be entered.
Lets look a bit closer at the action parameter. Most of it is pure SQL and we will not go through that. But we have some items with a percent in front of them that are of interest. When action parameters are feed to the DM certain keywords (words starting with %) will be replaced by something else (they are escapes). In our expression we have
%event.guid – Which will be replaced by the full GUID of the event that triggered this action.
%measurement.index – Which will be replaced by the measurement index of the sensor that triggered this action.
%isodate – Will be replaced by the current date on the form YY-MM_DD
%isotime – Will be replaced by the current time on the form HH:MM:SS
%measurement.float – Will be replaced by the measurement value as a floating point value.
I think you understand what will happen. Real floating point values will be written into the database with real date/time stamps and GUID and sensor index to identify the sensor that originated the measurement.
I hope its also clear that if you have an executable that can control something you will be able to control that ‘thing’ with the VSCP daemon.
Sending data to the cloud – method one.
ThingSpeak is a popular and free cloud service for visualisation and handling of measurement data. There are probably about ten thousand more services like it. Search. You can use ThingSpeak to, among other things, show real time diagrams of your data.
This is how it looks for the sensors from the fridge. Lets go through each of them before we explain how to generate them
The second row records OFF events received from the Paris relay module and writes a zero to filed4 when they are received. That is when the compressor is inactive.
That’s it. Not so complicated is it? You can use this method for most other cloud services as well.
Sending data to the cloud – method two.
As we wrote earlier the VSCP daemon have many more actions available than the execute external program we have used so far. One that is perfectly suited for sending data to a cloud service is the HTTP GET,POST,PUT action.
If you follow the link you will find two examples. The first use POST to update a field on ThingSpeak and the second use GET.
What method you chose is much a matter of preference.
Sending timed data using variables
If you look at the sample above you have learned that we can do timed actions as well using the VSCP daemon decision matrix. That is running an action every minute, very second or every hour or whatever. That is mor or less just like cron on a Unix/Linux system. This is possible using the internal events of the VSCP daemon. The events in this class is feed into the DM on regular intervals or when special things occurs.
So if we want to send data to a cloud service every minute we can trigger on the CLASS2.VSCPD, Type=6, Minute event. This event is generated once every minute. Now if we want to send updates to the cloud service every minute we have a problem if the sensor, as for the fridge in this example, updates every ten seconds.
The solution is to firts write the sensor value to a variable when the temperature event is received.
This is how this looks for the fridge temperature sensor. Action is 0x50 which is “store in variable”. This action is documented here. According to the documentation the action parameter format is
So we can create/write a variable fridgetemp with
That is the floating point measurement value is written to the non persistent floating point variable “fridgetemp” every time the temperature event from sensor 1 of the Kelvin NTC10K sensor in the fridge is received. We can use this variable from other programs.
Now all we have to do is to send this variable to the cloud service every minute.
First batch of cards for the Frankfurt Eth module (PIC version) arrived today. Now I just have to get the VSCP Sodium release out of the door, then finish that, and that, and that, and that… Can hardly wait until I can get this thing up and running.
Time to test Accra and to finish the code in this new module. The manual and the MDF is done (probably not final though) but if you are curious they are possible to check out now.
Kilafors will be a companion module to Accra for meter interfacing such as an electric meter that have an IR-led. With this module it is possible to get KWh measurement VSCP events just with some simple configuration of the Accra. No other coding needed.
Hardware work take much longer than one expect. We did know that when we started. Support and software takes time also. So at the moment we are quite a bit behind schedule. Some more modules are ready and designed and is just waiting to be tested and get code. Listed here for reference so you know what is coming this fall.
Vilnius is a general A/D module. Hopefully we see this in August together with Accra.
Kelvin 1-Wire is a temperature module that can use the popular DS18B20 sensor instead of a NTC sensor but otherwise have the same functionality as the Kelvin NTC module.
San Fransisco is a Barometer module.
Frankfurt Bluetooth is a BLE 4.0 interface that can be used to connect a cell phone or other Bluetooth device to a CAN4VSCP bus. This can be useful for diagnostics and configuration of a setup that is otherwise self contained, possibly for security reasons.
Roma802.15.4 is a module that have 802.15.4 and can connect CAN4VSCP segments with each other and connect some upcoming modules.
Roma 433 is a 433 MHz received/transmitter and can interface low cost 433 MHz equipment such as popular wall switches and temperature sensors.
Blitz which is a wifi interface to CAN4VSCP. This module also have a 433 transmitter and some more goodies.
That is what we have in the pipe. What we currently have components and boards for. But expect a lot of other things this fall from the Paradise of the Frog.
Other planed modules.
A gprs module that can be used for alarm and status and control sms is already available in our lab. This module can also be used to send and receive emails to get status from and control VSCP modules. Hopefully we will see this module in the Frogshop this fall.
A module we have had on the bench for several years now is Zeus. This is a module same as Odessa and with the same expansion interface but with Ethernet instead of a CAN4VSCP bus.
A simple low cost CAN4VSCP <-> wifi module is also in the pipe.
When we have the infrastructure in place with CAN4VSCP based, wifi-based i/f , ethernet i/f we will put all our efforts on our VSCP based Bumblebeez modules which are wireless low cost modules with a lot of exciting functionality. This means that we have VSCP connectivity over the most common transport mediums available and that they are possible to connect in a plug and play way.
We have today started work on our next module, the Accra counter module. The hardware is already done. This unit will be able to count pulses on four channels and also measure frequency on each channel. It can have alarms set for going over a counter level or when counting down to zero and for a frequency that is outside of a specified frequency range.
It has a built-in linear calculation algorithm that can translate pulse to real world measurement units. This can for example be used for utility meter measurements and gives the correct measurement value sent out on the VSCP bus.
Kilafors will be supplied later as an add on modules to detect S0 (IR) pulses so that Accra can be hooked on to an electrical meter and output power usage data.
This will be the seventh module in the CAN4VSCP series and will be followed by Vilnius for 12-bit A/D measurements.