GithubHelp home page GithubHelp logo

grodansparadis / vscp Goto Github PK

View Code? Open in Web Editor NEW
53.0 14.0 20.0 784.44 MB

VSCP (Very Simple Control Protocol) IoT/m2m framework

Home Page: http://www.vscp.org

License: Other

Python 2.56% Shell 0.32% HTML 3.31% JavaScript 0.39% C++ 58.41% C 27.07% Makefile 4.75% C# 1.26% Scala 0.01% Batchfile 0.07% Module Management System 0.06% M4 0.01% WebAssembly 0.01% PHP 0.01% CMake 1.67% Visual Basic 6.0 0.09%
iot-platform iot-application iot-framework iot-gateway iothub m2m home-automation can-bus communication vscp

vscp's Introduction

VSCP & Friends

License C/C++ CI Release Travis Build Status Project Status: Active โ€“ The project has reached a stable, usable state and is being actively developed.

You can look at device for device and create control software for each and one of them, we did it another way, we though of a black box device and created control software that works with everything that exists. One to unite them all.

VSCP (Very Simple Control Protocol) is a framework for IoT/m2m tasks. The framework defines methods to have a common device discovery, a common configuration, a common way to interface with remote devices and a common way to update firmware of devices built on different architectures. A server is available that runs on many platforms that have a webserver/websocket/rest/driver and tcp/ip interface with ssl security.

Documentation for VSCP is available at https://docs.vscp.org

Checkout with

git clone -j8 https://github.com/grodansparadis/vscp.git

A short introduction to VSCP is available here and here.

Documentation in different formats is available here.

Also there is a with many examples for different platforms and a HTML5 websocket UI repository.

Copyright (C) 2000-2024 Ake Hedman, the VSCP project - MIT license.

vscp's People

Contributors

blueandi avatar datenheim avatar davidlcamlin avatar grodansparadis avatar lmangani avatar retfie avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vscp's Issues

UPnP Support

Support for UPnP should be available in driver form.

Error: Could not find symbol 'CanalOpen' in dynamic link lib error127 - TCPIP Canel Driver

Hi, I am trying to compile and use the TCPIP Driver (Canel interface) I managed to compile it, but when setup in the daemon the above message is generated and no socket is opened.
There does not seem to be any CanalOpen entry proceedure in any of the drivers I looked at.

I am currently unable to compile the daemon due to libwebsocket issues so I am using the latest binary from git.

any pointers would be appreciative.

cheers,
Dusty

Make areas in Device Configuration Window resizable

Ake,

I have a feature request: the Device Configuration Window is divided into two main "areas": the receive area on the top, and the transmit area on the bottom. These area's are not resizable, which means that one cannot enlarge the receive area. When the whole window is resized, the transmit area is resize accordingly but the receive area is fixed.

I would like to be able to enlarge the receive area so that, when I select a receive line, I all properties in the area to the right of them fit. At the moment I can not see the "From GUID:" easily, I have to select the receive line and scroll down every time which is quite annoying. I have little interest in the send area (yet) so I would be happier if that were smaller and the receive area larger so all properties fit.

syjoz2 8

If it's not too much effort, would it be possible to allow the user to drag the division between the receive and transmit area?

Thanks in advance,
David.

Possible bug: action artifacts in DM row edit

Ake,

Suppose this scenario:

  • An MDF file contains the DM actions NOOP, ENABLE, DISABLE, TOGGLE and DIM.
  • Open device config window, click Update. The MDF is now loaded, registers read and contents parsed and displayed.
  • Go to the DM view, click a DM row, and open the Actions drop-down. It will list NOOP, ENABLE, DISABLE, TOGGLE and DIM.
  • Now edit the MDF file and remove the actions NOOP, TOGGLE and DIM. Leave ENABLE and DISABLE. Add a character in some description field to verify the correct MDF is loaded. Save the file.
  • In the device config window, remove the last character from the GUID to clear the registers view, add it again and click Update. The registers are re-read and contents parsed and displayed. Check if the added character is present (verification that the modified MDF has loaded).
  • Go to the DM view, click a DM row, and open the Actions drop-down.
    • It should now show ENABLE, DISABLE.
    • Instead it shows NOOP, ENABLE, DISABLE, TOGGLE and DIM. The three removed action somehow are still in the drop-down list, even though they are no longer in the MDF.
  • Close the device config window, re-open it, click Update, go to DM view, click a row, open the Actions drop-down.
    • It now shows ENABLE, DISABLE as it should.

David.

Varible autosave

Variable autosave should be added. Possible to configure how often save should be done.

writeConfiguration

The configuration of the daemon should have a routine to write it to file not just read it.

Typo in VSCPworks: "Full Uppdate"

Ake,

There's a small typo in VSCPworks v 1.0.0.47: in the Device Conf window there is a check box "Full Uppdate" on the bottom right of the screen. Obviously "Update" is spelled with only one "p".

Obviously it is a minor issue but just reporting it so that it can be fixed it in some next release..

David.

VSCP Works regsiter save/load does not work

Dear,

I have found what I believe to be a bug in the export registers to file funtion in VSCP Works. Running version 0.4.0.15.

Reproducing:

Open the device configuration window.
Load a node's registers.
Select "File" - "Save registers to file" and save into a .reg or .xml file
Select "File" - "Load registers from file" and re-load the file we just saved.
An error pops up saying "XML parsing error: 'not well-formed (invalid token)' at line 256.
When opening this file in a text editor (Notepad++) I find a value "0ร—" on line 256. There are a total of 4 occurrences of this value. When doing a search for this value and replacing any occurrences with "0x", VSCP Works is then able to import the file correctly. Note the subtle difference in the way the "x" is represented.

I believe there is a bug (typo?) in the export file code in the device configuration window.

Cheers,
David.

Constructor questions

  1. The the constructor init list is not used. This can be a performance issue. Is there any idea behind about not using it?
  2. In some constructors not all member variables are initialized, which could cause strange behaviour. Should we change that?
  3. Some constructors check the arguments and return in case of invalid parameters. But because of the return statement (instead of a exception), the object exists after the return and is in a strange state. Is there a rule not using exceptions?

:-)

VSCPworks 1.0.0.54 core dumps

Ake,

I have compiled & installed yesterday's vscp_software git pull. The deamon seems ok, but VSCPworks core dumps.

In one terminal I do:
sudo ip link set can0 up type can bitrate 250000 sample-point 0.875
sudo /usr/local/bin/vscpd -s &

In the other terminal I do:
root@ubuntu-john:~/vscp/vscp_software# /usr/local/bin/vscpworks &

  • Works starts
  • I open a client window, select interface, Edit, test connector or get interfaces -> core dump
    18:47:27: Debug: ============================================================
    18:47:27: Debug: Connect in progress with server localhost:9598
    18:47:27: Debug: ============================================================
    [1]+ Segmentation fault (core dumped) /usr/local/bin/vscpworks
  • I open a device configuration window, select my existing interface, click ok -> core dump
    18:53:25: Debug: strInterface =
    18:53:25: Debug: localhost:9598;admin;secret;
    18:53:25: Debug: strHostname =
    18:53:25: Debug: localhost:9598
    18:53:25: Debug: strUsername =
    18:53:25: Debug: admin
    18:53:25: Debug: strPassword =
    18:53:25: Debug: secret
    18:53:25: Debug: ============================================================
    18:53:25: Debug: Connect in progress with server localhost:9598
    18:53:25: Debug: ============================================================
    [1]+ Segmentation fault (core dumped) /usr/local/bin/vscpworks

Ubuntu Linux 14.04 LTS

VSCP client window: change connect/disconnect button behaviour

Ake,

Here's a small feature request again :-)

I find that the behaviour of the red Connected/Diconnected button is sometimes confusing. Would it make sense to change the colour of the button to green if connected and to red if disconnected?

Perhaps a small and seemingly insignificant change, but I've found myself disconnecting the client because I assumed red meant it was disconnected.

Thanks,
David.

VSCP Daemon "retr"-command

Hi,

The VSCP specification version 1.9.16 states in paragraph "14.6.19 Retr" on page 262 the following:

"If no argument is given one event is fetched even if there are more in the queue"

Is this still correct?
This doesn't seem to be true in my VSCP daemon compiled from source version 0.4.0.11:

retr
-OK - No event(s) available
retr
0,20,9,3,0,FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:00:01,0,255,0
0,20,9,3,0,FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:00:01,0,255,0
-OK - No event(s) available

Collect new discovered nodes

Collect new added devices with timestamp and present them in the web interface. Also let the daemon cache information from nodes on interfaces.

Question about a strange code in vscpwebserver.cpp

Hi Ake,

I found the following code construct several times in the vscpwebserver.cpp:

CControlObject *pObject = (CControlObject *)conn->server_param;

if ( ( NULL == conn ) && ( NULL == pObject )  && ( NULL != pSession )  ) {
  • First problem
    • Possible NULL pointer dereferencing in line 1.
  • Second strange problem
    • If conn is NULL, pObject points to somewhere, but no CControlObject.
    • And in case that really conn and pObject are NULL and pSession != NULL, pObject is used!?!?

Don't really know how to fix it correct, because I do not understand the idea behind. Please take a look at it.

Best regards
Andreas

vscpworks: extended page read register requests 0x80 registers to read

The device configuration requests 0x80 register, but according to VSCP specification 1.10.12:

An extended read/write response event is returned on success.
This means that a register (or a maximum of four consecutive registers)
located on any page can be read in a single operation.

If the node sends now only one extended page read/write response back, the device configuration aborts.

Neon release v1.0.0.43 WIN32 problems

Hi Ake,
I tried to integrate the vscphelper.lib and vscphelper.dll to the pc example of the framework.

This is story about it ;-)

  1. Copy include folder and lib folder stuff to my project.
  2. It doesn't compile, because some #include statements contains relative paths, which are not present at all. Solution for the future could be to use set them to the include path, instead of the #include statements.
  3. After changing it manually, it still doesn't compile, because the crc.h is missing.
  4. After I copied it from vscp-software trunk, it still doesn't compile and I found out, that in the vscphelperlib.h all WIN32 stuff is commented out.
  5. Ok ... after changing that again, its compiling ... yipiehh ...
  6. But after starting the .exe .... a dialog appears with SSLEAY32.dll is missing.
  7. I downloaded the SSLEAY32.dll from the openSSL project.
  8. Next try ... LIBEAY32.dll missing
  9. Same procedure, I downloaded the LIBEAY32.dll from the openSSL project.
  10. Now the program runs ...

Best regards
Andi

Issue writing paginated registers

Ake,

I noticed some strange behaviour in vscpworks 1.0.0.44 (git pull 8 dec '14). I was trying to write a register on page 1, but it got written to page 0 instead (page not correctly selected).

Suppose the following:

  • My MDF defines the DM to start on page 1, offset 0 (reg 1:0). There are 2 DM rows so the last DM register should be page 1 offset 15 (reg 1:15).
  • My node's firmware defines REG_DECISION_MATRIX as location 256, which should be reg 1:0.
  • If I read the device in vscpworks, in register 1:0 I find the same value as in reg 0:0. The next registers have the same behaviour.
  • If I update the value in register 1:0 to 0x51, the client window shows:
    • READ_REGISTER request for reg 0x92 (146). This is the first page select register.
    • RW_RESPONSE with data 0x00. So page 0 is selected.
    • READ_REGISTER request for reg 0x93 (147). This is the second page select register.
    • RW_RESPONSE with data 0x00. So page 0 is selected.
    • WRITE_REGISTER with the destination node's GUID, reg 0x00, data 0x51. So 0x51 is written to reg 0:0 here instead of reg 1:0.
    • RW_RESPONSE 0x00, 0x51 confirming that 0x51 was written to reg 0:0.
    • if I re-read the registers I can see that in fact 0x51 was written in reg 0:0.
    • If I dump the contents of my node's EEPROM to a serial terminal, I can see that indeed reg 0:0 was witten.
  • I was expecting:
    • 2 WRITE_REGISTERs to set reg 0x92 and 0x93 to page 1.
    • 2 RW_REPONSEs confirming that the page registers were set to page 1.
    • a WRITE_REGISTER to reg 0x00 and data 0x51.
    • a RW_RESPONSE to confirm the write.
    • register 1:0 to read 0x51.
  • If I manually send events:
    • WRITE_REGISTER 0xF9, 0x92, 0x00 (set page MSB to 0x00) (RW_RESPONSE 0x92, 0x00)
    • WRITE_REGISTER 0xF9, 0x93, 0x01 (set page MSB to 0x01 = page 1) (RW_RESPONSE 0x93, 0x01)
    • WRITE_REGISTER 0xF9, 0x00, 0x61 (write 0x61 to reg 1:00)
    • On the last write I get a RW_RESPONSE of 0x00, 0x9E while 0x00, 0x61 was expected. Strange.
    • If I check the registers in the device config window, I can't find the 0x9E in any of the registers.

Is this an error in vscpworks, or is it on my part? I suppose the latter since otherwise an obvious error like this should have already been noticed, but if so, where could my error be?

Thanks,
David.

Incorrect registers written in Dialog Edit Level 1 DM row

Ake,

Please try to reproduce the following:

  • open the vscpworks Device configuration window
  • read a node by setting GUID and clicking 'Update'
  • go to Decision Matrix view
  • Double-click a DM line to pop up the Dialog Edit Level 1 DM row
  • Change values to (any values really, but here's my example:)
    • Oaddr: 0x01
    • Enable DM row: 1
    • Check Oaddrr: 0
    • Hardcoded oaddr: 0
    • Zones should match: 0
    • Subzones should match: 0
    • Class mask: 0xff
    • Class filter: 0x14
    • Type mask: 0xff
    • Type Filter: 0x01
    • Action: 0x01
    • Action Param: 0x05
  • Click OK. Values are written to the registers.
  • Now check the DM row we just edited: all registers of that DM line are 0x05, and not the values we just entered.
  • Now double-click the DM line again, in the "Dialog Edit Level 1 DM row" change action param to 0x11. Click OK, all registers of that DM row update to 0x11.
  • Now switch to the Registers view, look up DM registers for that row, they are all 0x11.
  • If you change the DM register values in the Registers view, the values update fine, if you do it in the Decision Matrix view then all values in the DM row selected are overwritten with the action param value.

Do note that I am using a wonky MDF which I am still troubleshooting. Is this a vscpworks bug or is it because my MDF is wrong?

Thanks,
David.

Question about wxCmdLineParser

How should it be?

Like that one ...

wxCmdLineParser *pparser = new wxCmdLineParser( cmdLineDesc, argc, argv );

or that one?

wxCmdLineParser *pparser = new wxCmdLineParser( cmdLineDesc, argc, wxArgv );

I found both in the sourcecode. In case of using argv, wxArgv is prepared too, but never used.

Feature request: filter heartbeat messages

Ake,

I find that when monitoring VSCP traffic with the VSCP works monitor window, after a while the receive event window gets flooded with heartbeat messages. It would be nice if there was an option to filter out these events so that they don't appear in the received event window any more. Perhaps this is something of value which is easy to implement?

David.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.