Topics

1

V_Buscom / Multiple RTU's, single Data Blocks

« on: December 04, 2018, 08:45:06 PM »

I am trying to build a bit of a monster. Or at least, something that could be very VERY cool. Part of this process sees me learning a lot about MODBUS. Indeed, I'd never really touched it before I started trying to write an interface for it. Now I have a specific need -- a problem to solve -- and it is starting to take shape.

Here's the situation.

I have a single modbus device that only accepts one TCP/IP connection. It has multiple data blocks (registers) that it maintains, and that I sometimes need to update. Presently this device (master) is being connected to by a third party client. I need that third party to be able to maintain it's connection to this device, but I also need to get a connection to it. What I have devised and am trying to implement is this: A kind of multi-connection modbus datablock architecture. Or, put another way, a Modbus Splitter.

Basically I will create my own datablocks in Buscom that will mimic the real ones in the master device. Then I will connect myself as a slave to that master and poll it's registers at the same interval as the original client did. I will then ALSO provide a master and point the third party to me instead of the original master, thus putting Buscom in the middle, but it will actually be serving it's data out of the same datablock that is being polled from the original master. Now I can connect potentially any number of clients to me and share this same data with them as they please. Using pthread rwlocks should ensure data integrity while allowing reads from a significant number of clients simultaneously. (Really, I only need one extra connection.)

Now for the tun part -- doing it!

2

V_Buscom / The MODBUS Plugin Introduces a new Problem to the Plugin Architecture

« on: December 03, 2018, 01:47:49 PM »

I was very excited about the new plugin architecture. It was going very well, and several of the more "built-in" modules had been successfully converted to full blown standalone ones without much ado - including Lenel OnGuard's plugin and the one I'd created for talking to Simplex panels (well, listening to would be nearer the mark.) I started attempting to rebuild the MODBUS module as a plugin, and then decided to try to bring as much of the original code over as possible. That, however, is when I ran into the first new snag in this plugin architecture. The Base Object Name.

In Buscom, you have some core functionality that is accessed by top level items through vterm (the command line interface) such as channel or xmq. When you load a plugin, the plugin adds it's own base object as part of the linkage process, so that buscom's command handler knows what commands to pass on to the plugin's command handling routines. In the past, these have all been single items, but with the modbus module, I had designated multiple top level objects, including rtu and datablocks. This presents a problem, since you can at present only have one top level base object name.

There are a couple of ways to work around this:

• Prefix all commands with modbus - IE: modbus rtu 1 show
• Modify the base object designation to allow multiple items separated by a delimiter - IE: modbus|rtu|datablock
• Something else?

Personally, I am leaning towards the second option because it keeps in line with the rest of Venturii's norms, and offers the most flexibility for this and future plugins. It does, of course, require modification to the buscom code itself to strip out and parse the multiple base object names, but that is minor and trivial, really. Good. I'm glad that's settled.

3

V_Buscom / Asterisk Plugin Eyed on the Horizon

« on: May 16, 2018, 08:54:42 AM »

Last night I was reading through the API documentation for Asterisk, the free telephone service platform, and I believe there is a new plugin on the horizon for integrating with that system. Many (!!) years ago I set up an IBM XT computer with a Monochrome (green) display whose sole purpose was to open up a terminal, issue the AT+CID=1 command to a Hayes modem in one of it's many ISA slots and listen for the Caller ID data coming in off the phone line. Even then, it was perhaps overkill, but it was a rather convenient way to log incoming call history. Much later, early versions of Venturii had a Maestro module that provided similar logging of the call data, but also provided the ability to do things with this information by sending it to Decider. Thus we had a light that would flash whenever family called so we knew without having to get up if we should rush to answer the phone.

Now, having moved away from a land line and having a pure VOIP solution, my caller ID system still technically works, but I've had it in mind since the switch-over to integrate at an IP level to Asterisk itself. As it turns out, their AMI protocol (Asterisk Management Interface) appears to be just the ticket, allowing events to be reported through the connection and even calls to be originated and directed through this API. As with all things, it is only a matter of time now.

4

V_Buscom / Modbus Data Blocks

« on: May 16, 2018, 08:47:55 AM »

Originally my design was to have RTU devices own DataBlocks. DataBlocks are arrays of bytes which are either read from or written to by modbus commands. Each of these bits or bytes would have a corresponding VINT associated with it, and thus we could apply Venturii nomenclature to Modbus Remote Terminal Unit devices in a fairly sane way. This was all up and running and worked well, however as I've been working on this project my understanding of Modbus has grown and so too my desire to extend the functionality of this plugin even further.

The problem

We are integrating with a Modbus system that at present only accepts a single connection; subsequent connection attempts succeed but are immediately closed. When we disconnect the incumbent system, we can connect Buscom's Modbus plugin and interact with the Modbus devices through the connection, but this cuts off all access to the legacy system.

A Solution In The Works

I was talking to one of my colleagues about this problem, and he suggested we "Y-Connect" the TCP socket. Not a terrible idea, but because Modbus is a query/response system, it's not as simple to just cross-connect the thing like an NCC-1701 warp core. However the suggestion got me thinking, and the more I thought, the more I liked the idea that came to mind. What if, I thought, we open up the data blocks to more than one RTU device. We could even create slave RTU devices in the Buscom plugin, that would simply serve up data from one or more linked data blocks. In this way we could act as an intermediary between the existing Modbus equipment, legacy system, and continue to develop and interact with the hardware ourselves concurrently -- all on this same Modbus connection. In fact, this virtual data block could serve as an information for multiple RTU masters.

Using this topology we could shoe-horn the Buscom/Modbus plugin in between those systems. One RTU Master device would query the existing field hardware, update it's own copy of the registers & coils (stored in data blocks within the Bustom/Modbus plugin) and we would act as a slave to the legacy system which would poll [[us]] for updates. Our slave would serve up the correct coil and register data to the legacy host which would be none the wiser that it was talking to an intermediary now instead of the field hardware directly, and we can ourselves peek and poke at the data in situ.

5

V_Buscom / Lenel OnGuard Integrates with Venturii

« on: March 22, 2018, 05:30:56 PM »

Buscom now has a plugin to talk to Lenel OnGuard through DataConduIT. Of course, you need to buy a DataConduIT license from Lenel for your particular installation, but once you've laid out that chunk of cash, integrating your OnGuard Access Control System with Venturii is free. Here is what is presently supported:

• Venturii automatically generates DeviceIDs and appropriate VINTs for all the Readers, Inputs and Outputs in the OnGuard System.
• Reader Mode (Card Only, Locked, Unlocked, Card And PIN, PIN or Card, etc.) enumerates as a VINT with a source of Reader Mode.
• Door Forced Open, Door Held Open, Door Forced Open Masked, and Door Held Open Masked annunciate as separate VINT Sources with the same names.
• Access Control Doors can be opened from Venturii by sending a Desired Value of 1 to the corresponding "Open Door Command" VINT source.
• Input status from all Reader Inputs and Alarm Panel inputs enumerate as a VINT.
• Input Masked Status of all Reader Auxiliary Inputs and Alarm Panel Inputs enumerates as a VINT with a source Masked. Setting the desired value of this VINT will control the Masked state of the corresponding Input.
• Output status from all Reader Auxiliary Outputs and Alarm Panel Outputs enumerate as a VINT. Setting the Desired Value of this VINT controls the output (0=De-Energize, 1=Energize, 2=Pulse).

More features are coming soon! This means that you can use any of the web-based user interfaces to view the status of various points within your Lenel OnGuard Access Control System, or you can create new ones with the new User Interface System, code named ProximaVenturii. More details on that will also be coming soon!

6

Decider / Websockets JSON and Web UI Control Surface Pages

« on: February 20, 2018, 04:16:03 PM »

I re-implemented a function today at the request of JH whereby upon registration of one or more VINTs for a Websocket session, Decider will send the current values and Device Status of all registered VINTs to the client in a single JSON object (an array) like so:

Sample Request:

Code: [Select]

{"RegisterVUIDs":["1","5","9"]}
Sample Response:

Code: [Select]

{"VintValues":[
   {"VUID":1,"DeviceStatus":1,"Value":2000},
   {"VUID":5,"DeviceStatus":1,"Value":2000},
   {"VUID":9,"DeviceStatus":1,"Value":2000}
]}
One thing that occurred to me, and this from a place of ignorance about the way in which JH's node.js web interface works, as he changes pages from one control surface to another, it is possible (likely?) that the client will retain the web socket connection, but need to register for a new set of VINTs (and possible un-register other VINTs) While there would be nothing wrong with keeping them registered, we would simply send values it had no place to display, at present there is no mechanism yet in place to unregister VINTs within a given session. A couple of options lay before me:

• Implement an UnregisterVUIDs command.
• Instruct the client to disconnect and re-connect when a new set of VINT subscriptions is required.
• Do nothing (Keep all registered VINTs in the session and continue to send their updates.

I'll probably go with option #1, but is there any other option I am overlooking? Is there an advantage to going with #2 or #3 that is not apparent?

7

V_Buscom / Crossroads

« on: February 08, 2018, 11:06:52 AM »

Now it comes to that time. Decision time. A Fork In The Road. Buscom appears to be working nicely, and is nearing the point where I would be cloning it into a new project to begin implementing the Mosbus connectivity. But herein lies the crossroad: Is there any benefit to making that an external module versus just incorporating the modbus functionality into buscom? Obviously it need not be utilized if not needed, but what reasons could be contrived to have them separate? Perhaps there is an argument to be made here for using the codebase as it is as a plug-in host for all manner of device-specific processing, since all the other code largely remains the same. I'm thinking of revitalizing the DSC integration module, but again - it would essentially be based on buscom with all it's established code and functionality. I wonder if there might be a way we could standardize on the buscom code and somehow create "plug-in" modules that interact with specific hardware, building on what we've already created. This would simplify the maintenance of code, bugfixes and enhancements to the core would need to be applied to each and every module. What does a modularized system even look like? I've never built "kernel modules" (well, built - yes. Designed / coded: no.) We'd need some demarcation point, probably after the channel had been connected, to turn processing control within each thread over to a function within the module space for "doing something" with that connection, whether that be querying one or more devices, listening for data, or what have you. The module space code would need to be able to allocate it's own memory and Venturii Value Interpreters, generate it's own events, etc. Perhaps this may even be a good place to introduce Lua to the mix, and code the module-specific stuff in Lua script (if that's even what you call it.)

Within the Modbus module, for example, there are dozens of registers, each one holding 16 bits of data. My plan was to create the modbus module such that when you created a channel, you would then add a device (similar to the vdac system) and tell that module how many registers to allocate and the starting address within the PLC. This would then create n * sizeof(register) Value Interpreters (since for us to be able to do things intelligently within Venturii, we pretty much need access to each individual register as a separate entity that can be read and written to independently of all the others. While not the most efficient use of space, (multiplying storage by at least a factor of the functionality requirement outweighs the "waste of bits". But then from there, we haven't much to do. Read all the registers, set the values of each register if any of our VINTs have dvals set, and sleep between poll cycles. The module code would retain control until or unless an error condition occurred by which it became apparent (or desirable / necessary) that the underlying channel connection be reconnected. The module space code need only return (or maybe call some "disconnect()" function and then return) to pass control of the thread back to the buscom code base, which would try to re-establish the connection.

Hmm, the more I think of it, the more I like this paradigm. In fact, i can see all the Venturii modules unifying under this architecture, which would simplify a LOT of code, partially by actually removing most of it, and then only incorporating the device or hardware-specific code itself within these modules. You could even have a single Venturii module talking to many different device types, all within the same process. Arguments could be made on both sides of the table for or against this approach from a single-point-of-failure, redundancy, division of labour or many other basket-to-egg-ratio perspectives, but having the option to hold all the eggs would not mean you couldn't then run multiple "baskets", even having a separate basket for each egg.

This is why I love writing these things down and working them out in text; great ideas form this way and I'm sure down the road it may even be interesting to have a record of the thought process as it formulated within my mind! Haha  The inner workings of my brain on display. Viva Venturii!

8

General Discussion / Snow Day!

« on: February 08, 2018, 08:23:49 AM »

I climbed up on the roof of my garage a few days ago to clear off the snow from my solar panel, only to wake up this morning to another 25 cm of snow sitting on the roof. The entire solar panel is buried so that you cannot even make out where it lays on the roof! Everyone is staying home today. It is remarkable how much snow can accumulate!

One of my favorite sounds on a frigid day like this is the gentle Ahhhh of heated air rising through the vents in the floor, warming the house. Venturii calculates the difference in temperature between the inside air and outside air, and adds more heat inside when it gets colder outside to compensate for the accelerated heat loss through windows, walls and ceiling. I've been wondering and doing a bit of research on applying hot water lines to the underside of the floor sheathing - particularly beneath the stone tiles that lay inside our front, and back doors and main floor bathroom that always feel cool to the foot. Even if we could raise their temperature by a few degrees, it would go far to take the edge off. In my mind a simple recirculating pump and a couple of zone valves could control the flow of hot water from the hot water tank, out through the heating loops and back into the tank. I'm not sure if there would be any issues with doing this with shared domestic hot water, but I guess that's where further research comes into play. Ideally I'd like to do one zone for the front entrance, one for the main floor washroom, one for the kitchen / dining room and one for the back entrance, though it may be more difficult to get lines under the back entrance since part of the basement beneath it is finished. Eventually when we finish the rest of the basement, we'll probably (most likely) do some sort of in-floor heating. I've been in basements where this is the case and it's funny - the effect is so subtle you don't even notice it until you step into the furnace room or some part of the basement without in-floor heating you are suddenly (and startlingly) aware of the difference. For that project, I may even consider electric in-floor heating, thought I am loth to use electricity for heating anything but my tea since it is the most expensive form of heat available here, despite the convenience and ease of precise control.

9

V_Buscom / Buscom - The New Mod Shell

« on: February 05, 2018, 03:55:38 PM »

Years ago I started creating a Venturii module coined Modshell that was designed to be a generic code base from which to easily whip up new modules as I encountered additional systems to integrate Verturii with. Modshell has trailed behind the leading edge of development, though it's concept has recently been revitalized by the development of Buscom. Among other things, Buscom essentially accomplishes one of the same goals Modshell was supposed to.

Buscom is a generic Venturii module. Unlike every other Venturii module which was created to interface with a specific system or piece of hardware, Buscom has been designed to interface with interfaces, not devices. What that means is that Buscom includes all of the code necessary to set up the following connection types:

• TCP Server (Remote device connects to a listening TCP socket served by Buscom)
• TCP Client (Buscom connects to a listening TCP socket served by some external host
• UDP Server (Remote device connects to a listening UDP socket served by Buscom)
• UDP Client (Buscom connects to a listening UDP socket served by some external host
• Serial Port (Buscom connects to an external device over a native (16550 or similar based UART) or USB-based Serial Port
• (Unix) Named Pipe (Buscom connects to another service running on the same host that can communicate over a named pipe

Having established a connection to one or more of these connection types, data can be sent directly to and from that device through Decider. One of the first simple uses I had in mind for this was to set up a dot matrix printer that recorded a log of sorts, printing one line at a time as it was received from Decider. All Decider needs to do is generate a string of text and send it to the appropriate channel on the corresponding Buscom module, and that string will be delivered verbatim to that printer. This, as it turns out, has many other practical uses as well. It turns out that many systems utilize a simple yet powerful system for providing API's to their inner workings. This will actually be the basis for both the Pelco Endura integration and the Harding DXL Intercom System integration, both of which use simple, low level serial protocols for allowing external control of their workings.

Today I have begun returning my focus on Buscom, with the plan being to clean up it's code, run it through a series of tests (including both functional and performance & memory usage - IE: Valgrind) before I begin to fork this project and create a new one, the first child of Buscom, which will be a Modbus module for talking to RTU devices using the protocol already named.

10

Web-Based User Interface / Developing a new Web Interface Framework

« on: February 02, 2018, 10:15:28 AM »

One of my colleagues has been putting forth considerable effort on developing a new web-based user interface framework for Venturii. From what he has told me, it is built using Angular, though I am not familiar with this technology at the moment. Still, one of the things I love about working on Venturii is that it gives me time and cause to investigate things like Angular with a specific purpose and task in mind. This makes it much easier to focus one's attention to a task with real goals in mind; I find this approach much more productive than simply trying to work my way through hello world examples that are purely conceptual and have little application to anything I am working on. Hopefully this colleague shall join the forum here (he's complained about the site's certificate so I may need to get that fixed) but he brings a wealth of information, experience and value to this project and could contribute much to the development of Venturii.

11

VSAC / Obsolete

« on: January 31, 2018, 01:26:08 PM »

This firmware, while once intended for a separate PCB design, has now been merged with the main VDAC code base. I believe myself and Mark are the only two people now with running VSAC boards... These will eventually get updated with VDAC firmware, which adds much functionality and requires no hardware changes.

12

Decider / WebSockets JSON Communication Protocol

« on: January 28, 2018, 09:25:36 AM »

In order to help facilitate and expedite the Web User Interface development, I have begun implementing a new WebSocket protocol that exchanges messages in JSON format. The development of this protocol will be described here, since it is also a good medium in which to discuss the development process and its' progress.

13

Energy Management & Monitoring / Venturii Smart Water Meter Reader

« on: September 26, 2017, 10:46:15 AM »

I am very excited to announce that the initial test runs of the prototype Venturii Smart Water Meter Reader have gone VERY well, monitoring in real time and logging every 1/100th of a gallon of water used in my house! It is able to report Flow Rate, totals per day, and the Venturii graphing engine is presently displaying cumulative values organized by minute, hour, day, or month.

I've long been quoted as saying that the first step to reducing your consumption is to monitor it. In our house of 6 people, I know that we use a fair bit of water, between the toilets, laundry, 6 people bathing / showering, the dishwasher running each day plus irrigation during the summer months. Now with this exciting device, you can affix real numbers to those values and say things like "We used 348.4 gallons of water yesterday." Once you get an idea of how much you are using and start measuring it in a meaningful way (let's face it, seeing the grand total in cubic meters once a month does not drive meaningful change in consumption behavior) - you can begin to change the way you think about water, it's use, and the conservation thereof.

I will be posting more information about this product soon! 

14

General Discussion / BBS / Forum Back Up!

« on: September 26, 2017, 10:34:26 AM »

It's been a few months, but the BBS is back up. This took a back burner as I had upgraded from Fedora 24 to Fedora 25, which changed from PHP5 to PHP7 in the process. At first there was no version of Simple Machines Forum compatible with PHP7, so I waited. After a quick check today I found this version had been released, installed it, and voila! We are back up and running.

Now we just need to get Mark's Venturii system upgraded to the latest software and firmware versions, and we need to get some Venturii devices and software running at Jeremie's house, and hopefully that will generate some feedback and chatter on this web site as we work together to make this great system even better!

At least that is my hope... 

15

General Discussion / Logging Events to an Oki Microline 420 Dot Matrix Printer using a D-Link DP301P+

« on: January 18, 2017, 10:52:16 AM »

Last night I started working on an interesting project. In the 80's movie Sneakers there is a scene at the Playtronics Toy Corporation headquarters where someone swipes their card (yes, it is a mag stripe!) through a card reader, and the camera zooms in on a Dot Matrix printer that prints a line recording the transaction directly to paper. I've always wanted to do that and so finally had an opportunity to look into it. I picked up a couple of Oki Microline 420 dot matrix printers on eBay for a song, and there is nothing wrong with them - in fact, they're actually pretty nice printers as far as the Dot Matrix models I've worked with over the course of my life.

The trouble started with the print server I bought off of eBay also. It came without any details, and turned out to be set to a static IP address and had a password set. It turns out this little guy does not have a physical reset button. I even pulled the cover apart to look for any signs of an obvious "reset pin" inside - nothing leaped out at me. Some posts online suggested using the username of psadmin and the password SYSxxxx where xxxx is the last four characters of the device's MAC address in caps. I tried every combination of case, along with a variety of usernames (admin, psadmin, user, manager, system, etc.) - all with no luck. Then I stumbled across another web site that suggested a URL on the device that bypassed the question altogether and allowed me to either reset (reboot) the device or factory reset it. I chose the latter, and a few moments later, it was fully factory reset. For the life of me I cannot find that site on Google right now, but I will check again when I am in front of the computer that I actually retrieved it from. In any case, I was then able to configure the print server and could print test pages from it to each of the various dot matrix printers I have, but getting it to print lines of text at a time from any Linux computer over the network took some more twiddling.

In the end I came up with a way of using lp to accomplish what I wanted to, and the only downside was that each line it printed created a separate "print job" that went through the cups spooler, but apart from what appeared to be some bloat, it did in fact print my lines. Now to get Venturii to produce those lines of event log text for the printer to encode on paper!