I planned to release version 15.0.0 of VSCP today. But as usual plans are one thing and reality is another. I still need some more time. But very soon now...
This has been a very hard release to get out. Mainly because the big rewrite of code. The rewrite has taken nearly two years to accomplish so there are many, many, MANY changes.
The biggest change is that MQTT is used for higher level functionality now. This means that the drivers (both level I and level II) talk to a MQTT broker in the following fashione
It is actually possible to have as many subscribe/publish topics as one need. Like this
So from a higher level view you now subscribe or publish VSCP events on a MQTT broker of choice. Events that can be on four different formats; binary, JSON, XML or ASCII.
The default format is JSON. Ans a VSCP JSON event looks like this
The tcp/ip interface, the web socket interfaces, the decision matrix, the webserver, remote variables are gone from the VSCP daemon with this release. From tghis point the VSCP daemon will do one thing. Have a common interface to drivers and handle the transfer of events between the drivers and MQTT brokers. One can look at it as a pluggable driver interface for MQTT brokers.
Well, a lot of functionality has been written during the year using the VSCP web interface, websocket, tcp/ip etc. But that work does not need to be thrown away. This functionality is now available as drivers to the VSCP daemon. Initially the tcp/ip server and client, the web interface, websockets (ws1/ws2) and the rest interface is in place. Later the decision matrix functionality and remote variables will be added again as well.
Another news is that the VSCP daemon natively now builds on Windows again. Many have asked for that. Most driver will be available there as well.
There are more of course. But more on that latter. If I sit here and just write about the release it will never come out.
Last I want to thank my sponsors. It has been a tremendous help during this long development time to get this sponsorship. It’s been that little drop of water that made the boat go float each month. Thank You!
psWhat about VSCP works someone may ask? The rewrite works continue isd trhe answer. A lot to rewrite there as well.ds.
Well it’s the “IoT standard” as long as this is transferred over MQTT.
Not a single of the fields above is in any way “standardized”. No consensus around with anything. Not even a topic.
A tiny device will have problem when reading this type of textual information.
Result: Fragmentation. No one understands anyone else data.
The solution
The solution for many is to do another definition of the above. Yes it is NOT an intelligent approach. It’s just like banging your head against a wall over and over again.
VSCP started to look at things from the other end for more then twenty years ago. Her the standardization was centered around what you send and not what you send it over.
VSCP consist of a set of well events with defined content.
You know what to send.
You know what to expect to receive.
Yes also from someone else.
This content can be transferred on many different transport mechanism. Yes MQTT to. You still know what to send and what to receive.
Look at a measurement unit for example. Is a temperature given as A Kelvin temperature, a Fahrenheit temperature, a Celsius temperature? Well all are defined in VSCP. Actually all SI units and SI defined units are defined with pseudo language conversions between the units.
For a tiny device the byte order and coding of data is important. In VSCP all that is well defined. Byte order is always big endian. No exception. You know what to get an how to interpret it.
So for a temperature measurement in VSCP for example the above would have the form as below if we use JSON (more info here)
vscpHead – This a bitfeiled with flags with different meaning.
vscpObId – Applications can use this 32-bit unsigned integer, the way the want. Typically used as a session id or similar.
vscpDateTime – UTC date and time. If not set the current UTC time is set.
vscpTimeStamp – Microsecond precision timestamp. A relative time that can be used to measure very precise inter event timeing for events from a specific device.
vscpClass – The VSCP class is a code for a group of events. Typical a VSCP class specify events for alarms, measurement, information etc etc. For a temperature it is coded as 10. But as events are such a common IoT property there is a group of VSCP classes available for measurements. Check the VSCP specification for available events.
vscpType – The VSCP type identify the actual event in the VSCP class. For a temperature it is coded as 6.
vscpGuid – This is a globally unique id for the device sending the event. The event can be derived from most other id’s such as a IPv4 or IPv6 or MAC address. More about VSCP GUID’s in the VSCP specification.
vscpData – The event data. Well defined content. Max 512 bytes. Or just eight in constraint environments. Defined to be easy to read rfor machines – not for humans.
For the measurement extra filelds
value – A floating point value for the measurement.
unit – The unit for the measurement. Set to zero for the default unit. For temperature this is Kelvin. Unit 1 is degrees Celsius and unit 2 is degrees Fahrenheit.
sensorindex – A device can have many sensors. The sensorindex is the id for a sensor on a device.
zone/subzone – Used for grouping of devices and sensors. Can be sensors in devices in a specific location.
Why is a well specified format an advantage
Most important. If you know what to expect you can write handlers once and then reuse them for many cases. Also you can user tools developed by others in your setup. A typical example is a graphical presentation. Write it for one type of measurements and the same solution will be valid also for other types.
Same is true when you send things. To turn something on/off is as clear and concise as sending a measurement value.
It all will work on a constraint environment such as a CAN-bus as well as over tcp/ip.
Why do it all again and again and again, instead of once. Join the free, open and gratis world of VSCP.
A PCB to interface the smartmeter is available here
This is how the new electricity meter look slike that was installed here this week. Apparently, 5.4 million new meters will be out before 2025 (Swedish). Yes, I have been collecting data from its predecessor (which was only installed here for two years) for quite some time. S0 pulse was not available to ordinary people like me but the flashing IR diode was. So power and energy I have logged. I have another meter in my office too. Reads S0 and IR there and can thus distinguish between the house’s total electricity consumption and the office’s electricity consumption.
But the new electricity meter promised more. A serial interface for customers. A HAN gate. Yep, definitely something that definitely start a guy like me up. A few minutes after it was installed, the customer interface was activated. Just go to Ellevio’s “my pages” and activate. Smooth.
Unfortunately I did not go ahead with building the interface logic required to be able to read out values from the interface the day it got installed. Had to (impatiently) wait to the next day because I had other things to do. But it was very simple. A transistor, some resistors and a USB to series converter are all that is needed. After it is built a Raspberry Pi could read the information that the meter sends out. You could just as easily use an ESP32’a or an ESP8266, Arduino, or a PC of course. Nothing strange, expensive or advanced here.
The new meter provides current and voltage and active and reactive load on all phases separately. Add summed energy to that. Yes, both in and out. If you are someone who has a wind turbine or solar panels in the yard the in readings is for you. Goddies for those of us that like data. All data is sent out every ten seconds from the meter.
The serial format is unencrypted with speed and format 115200, N, 8.1. Just standard. However, it is sent inverted and with TTL levels so you have to take care of that.
The contact on the electricity meter is an RJ12 as below
The meter sends data on pin 5 when D_Rqst (RTS) is high. I have tested the circuit below with both 5V and 3.3V and both work great so interfacing most hardware should be no problem as long as it has a serial port or can emulate one.
If you look at what the interface on the meter looks like, you understand that both 3.3V and 5V work.
A simple circuit is all that is needed to adapt this to a USB TTL serial adapter I used or to the serial channels on a Raspberry Pi, Arduino or other device.
Select 5V for VCC if rx is to be connected to a 5V input (Arduino etc), otherwise select 3.3V (ESP32 / ESP8266 / Raspberry Pi etc). In my case, I use a USB to series adapter that can handle TTL levels. Remember to also connect the earth to the device that will read the data.
If you use a USB to series adapter like me and Raspberry Pi, it will be available as /dev/ttyUSB0, /dev/ttyUSB1, etc when connected. With the Minicom program you can look at the raw data. Install Minicom with
sudo apt install minicom
If you want to be able to open the port without “sudo”, you should add the user you are running under (usually “pi“) to dialout in the file /dev/group
Use the nano or vim editor or your own favorite editor to do this.
Now run Minicom with
minicom -b115200 -D/dev/ttyUSB0
Change the serial port to the port you use and add sudo if you did not do the change in /dev/group.
The command line switches speak for themselves. But for safety’s sake, we take them. -b sets the baud rate. -D indicates the port you want to communicate on. Of course you change to the port you use. If all goes well, the following is printed on the screen every ten seconds.
In the linked document above, there is an appendix 3 that tells what the type of data is for each line. Easy to parse with our code.
To exit Minicom, type
ctrl-A Z X
and select “yes” when asked “Leave Minicom?” Best to write it because the sequence is not the first one you come up with. Trivial if you know it, not so if you don’t.
It is not more than that. Now just write a program that reads these values and lists them in charts and tables. node-red is a great tool to use for this. node-red can read from a serial port directly or you can write a script like this in Python
import serial
sio = serial.Serial(
port='/dev/ttyUSB1',\
baudrate=115200,\
parity=serial.PARITY_NONE,\
stopbits=serial.STOPBITS_ONE,\
bytesize=serial.EIGHTBITS,\
timeout=12)
print("connected to: " + sio.portstr)
count=1
while True:
line = sio.readline().decode('ascii')
if (-1 != line.find("1-0:31.7.0")):
print("[" + line + "]")
print("Fas L1:"+line[11:-5]+ " " + line[-4])
print(float(line[11:-5]))
Preferably, you then send the data to an MQTT broker or similar instead of printing it. A little fun coding for a boring evening maybe.
I have put together the project vscp-python-p1-power-meter which sends sensor values to any MQTT broker. If you do not like VSCP, the code can be easily adapted for other formats. I think the code is pretty easy to understand. Configuration takes place in the config.ini file and you have documentation on the code page. Below is a screenshot from MQTT explorer showing MQTT VSCP data for voltage, phase 1 delivered in real time
And below the current data for the same phase
Note the diagram at the bottom right. A smooth feature in MQTT explorer to quickly visualize data.
This is what it can look like when data is presented in node-red
But it is very easy to create your own website and present live data there if you first send it to an MQTT broker taht havae websockets enabled. If you send VSCP events over that interface instead of some other random data, you have a solution that is both scaleable and reusable at all levels. I may do a howto on that to later.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok