Part creative code, part artisanal Pi enclosure, part clock.
Source: Concrete Physics Clock | Hackaday.io
Nice work!
Categories
Designed for simple and secure connectivity applications, Espressif has introduced ESP32-C3. ESP32-C3 is a cost-effective, RISC-V-based MCU with Wi-Fi and Bluet
Source: RISC-V MCU Blends Wi-Fi and BLE Connectivity | Circuit Cellar
Categories
VSCP daemon – next version peek
It is now possible to use tokens instead of numbers in events published topics from a driver and from the VSCP daemon itself. This is accomplished by using {{class-token}} and {{type-token}} instead off {{class}} / {{type}} so a topic for the above can look like
vscp/{{guid}}/{{class-token}}/{{type-token}}/{{nickname}}
Note that also {{nickname}} is set here to make it easy to filter on events from a specific node.
The current list of substitutions that can be used is
{{driver-name}} – Name of driver receiving ten event,
{{guid}} – Full GUID on standard form.
{{guid0}} – {{guid0}} – A specific GUID position.
{{guid.msb}} – MSB of GUID.
{{guid.lsb}} – LSB of GUID = nickname for can4vscp.
{{ifguid}} – GUID for interface the event is received on.
{{nickname}} – Nickname for node sendning event.
{{class}} – VSCP class
{{type}} – VSCP type.
{{class-token}} – VSCP class token.
{{type-token}} – VSCP type token.
{{head}} – VSCP event head.
{{obid}} – VSCP event obid.
{{timestamp}} – VSCP event timestamp.
{{dt}} – VSCP UTC datetime string.
{{year}} – VSCP event year.
{{month}} – VSCP event month.
{{day}} – VSCP event day.
{{hour}} – VSCP event hour.
{{minute}} – VSCP event minute.
{{second}} – VSCP event second.
{{clientid}} – Client id set for driver.
{{user}} – User set for driver.
{{host}} – Host set for driver.
There will probably be more added as we walk the path against a release.
Categories
VSCP Google group terminated
With no activity on the VSCP Google group for a long time I have now removed it as it does not have any value for the project any longer.
Please use Github Ãnstead.
A new version of the package node-vscp-type (1.0.12) was published at 2020-12-04T14:46:26.187Z Updated to latest class/type definitions
A new version of the package node-vscp-class (1.0.14) was published at 2020-12-04T14:45:06.427Z Updated to latest class/type definitions
New version that remove directional part of topics which is specified by the VSCP standard document.
Available on PyPi
Docs are here
Categories
New release of pyvscptypes 0.0.8
Categories
New release of pyvscpclasses 0.0.8
Working hard here on the next release of the vscp daemon dubbed Phosphorus with version number 15.0.0. If nothing strange happens there will be an alpha release next week.
Just want to to share a hint on what is to be expected from the new release. In short I can use one word for it
LESS
A lot of functionality was removed from the vscpd Silicon release. Now even more core functionality is removed.
- The web server is no longer.
- The multicast and udp support will be a level II driver.
- The tcp/ip interface will be moved to a driver.
- Both websocket interfaces will be moved to drivers.
Added is extensive MQTT support. Meaning that all MQTT tools out there will be useful for VSCP work as well.
This is how it works
The daemon itself will publish events to a configured broker. It can subscribe to as many topics as one like and also publish on as many topics as one like. One topic is a retained topic (typically “guid/interfaces”) which holds a JSON formatted list of interfaces on that daemon. More will come here as we go.
Full control of the topic with some dynamic possibilities such as guid/class/type/nickname etc
Drivers are the same. The can subscribe on as many topics on a selected broker as one like and also drivers can publish on the needed number of topics.
Level I driver config
A level I driver get a new configuration format that looks like this
<!--
The Level I socketcan driver (You may concider using the
Level II version instead)
-->
<driver enable="true"
name="socketcanl1"
config="can0"
flags="0"
translation="0x02"
path="/var/lib/vscp/drivers/level1/vscpl1drv-socketcan.so.1.1.1"
guid="FF:FF:FF:FF:FF:FF:FF:F5:01:00:00:00:00:00:00:03" >
<!--
The MQTT settings for device
-->
<mqtt host="192.168.1.7"
port="1883"
user="vscp"
password="secret"
clientid="vscp-drv1-socketcan1"
qos="0"
bcleansession="false"
bretain="false"
keepalive="60"
cafile=""
capath=""
certfile=""
keyfile=""
pwkeyfile=""
format="json" >
<subscribe topic="vscp/{{guid}}/#"
qos="0"
options="0" />
<publish topic="vscp/{{guid}}/{{class}}/{{type}}"/>
</mqtt>
</driver>
Much the same with the added MQTT connection information. MQTT config data is inherited from the main process so if it is the same no need to set it again in the driver.
Level II driver config
Config files for level II drivers looks like this
<!-- Level II tcp/ip link -->
<driver enable="true"
name="tcpiplink"
path-driver="/home/akhe/development/VSCP/vscpl2drv-tcpiplink/linux/vscpl2drv-tcpiplink.so.1.1.0"
path-config="/home/akhe/development/VSCP/vscp/debug/linux/vscpl2drv-tcpiplink/driver-conf.xml"
guid="FF:FF:FF:FF:FF:FF:FF:F5:22:00:00:00:00:00:00:55" >
<!--
The MQTT settings for driver
-->
<mqtt host="192.168.1.7"
port="1883"
user="vscp"
password="secret"
clientid="vscp-drv2-tcpiplink"
qos="0"
bcleansession="false"
bretain="false"
keepalive="60"
cafile=""
capath=""
certfile=""
keyfile=""
pwkeyfile=""
format="json" >
<subscribe topic="vscp/{{guid}}/#"
qos="0"
options="0" />
<publish topic="vscp/{{guid}}/{{class}}/{{type}}"/>
</mqtt>
</driver>
Pretty much the same as before but with the new VSCP level II driver interface which has many new features.
VSCP tcp/ip link interface
The biggest change is probably that the tcp/ip link interface will go. This does not mean that it will not be used anymore. It will still be supported all over the place including in the new VSCP Works version. The link interface is still perfect for higher end hosts and the tcp/ip link driver can connect them all now and will do so in the future.
What do you need to do as a user
Nothing. The current version of the VSCP daemon will still live on until there is a stable version out of the new VSCP works. When that happens the shift will take place. Hopefully sometimes in the spring next year if all goes well. But don’t take my word for it, last year I would have thought it should be out and working already months ago.
If you want to test
The development is carried out in the developer branch och the vscp project. Just clone. configure and make. I think the configuration file is rather straight forward and talk or itself. New manual info will be available soon.
So exciting times for VSCP ahead. It can be only me of course that think that way, but never the same, I think this is rather fun.
/Ake