Messages

46

Console-Based User Interfaces / Console Versus Graphic vs Web User Interface

« on: December 26, 2015, 10:40:29 AM »

One of the first challenges I came to while designing Venturii was the form of user interface to use. On the one end of the scale you've got console-based interfaces, which offer practically unlimited access to every feature, parameter, command, and option. But they're not pretty, and can be daunting for the inexperienced or unfamiliar to approach. At the other end of the scale you've got pretty web interfaces, but often that visual appeal comes at the cost of depth - you simply cannot put all the controls on a web page or it quickly becomes unmanageable. Thus, function gives way to form as the most important options rise to the forefront while the more advanced or lesser-used features sink out of sight. The end result was actually a hybrid of the two, where there is a console interface for all modules that allows access to everything, while more data / less configuration has made it's way to the front end web interface. Actually I'm in the process of re-writing Decider so that much more of the configuration can be done from the web interface, but that's topic for another post in another forum. This forum discusses the console interface.

One of the first things on the TODO list for the console is the unification of all the commands - Mark has lamented numerous times how sometimes the same command has a different syntax in different contexts. This is, of course, the inevitable result of writing different components at different times, and perhaps a hint of laziness as the better practices discovered in more recent work was not backwards-applied to older code. However, I've been trying to use the bug tracker (http://venturii.net/bugs) to identify each of these anomalies so that they can by systematically corrected in time.

47

General Discussion / Oh How I Hate Spam!

« on: December 13, 2015, 05:42:42 PM »

It's 2015. Part of me cannot believe that we still have spam. Yet this forum has experienced a rash of new users signing up with the sole and express purpose of posting spam as though it were legitimate content. As such, I've changed the new user registration policy to require E-Mail verification, and if spammers continue to be un-detererred by that measure, I will have to take more drastic measures. Of course, at this point our traffic is pretty much exclusively search engine bots, but I hope that as I write more and more about Venturii and what I'm working on <behind the scenes> that others may pick up some of the topics found through similar searches and begin to contribute to this site.

48

Energy Management & Monitoring / Re: The Downside To Energy Monitoring and Management

« on: December 13, 2015, 05:38:35 PM »

There is definitely something to be said for the bliss of ignorance when it comes to energy usage. The more I peruse my graphs and produce increasingly granular reports on energy usage and commodity consumption, the more I feel a deep-seated urge to try to increase the efficiency of things.

Efficiency can be gained by numerous means, the simplest of which is to simply not use a resource.

Turning things off is probably the easiest goal to achieve with any automation platform, and Venturii is no exception. By using Passive Infrared and other forms of occupancy sensors, it is a trivial matter to have Venturii turn off the lights in a space when that space is unoccupied. I've even taken it a step further, utilizing a recent feature addition called Torx Pegs which allows me to do things at regular intervals. I've implemented a new set of instructions that cause Venturii to turn off every light in the house during the day on an hourly basis, providing it is very bright outside. This becomes a bit of a catch-all, especially for areas of the house that do not have occupancy sensors like the kitchen and dining rooms, areas that are often used and often left lit, unattended. Because the Torx peg restricts this sweep to once per hour, it's generally been received by the family as acceptable; if the lights get turned off when my wife is in the kitchen during the day, she simply turns back on the ones she needs to.

One of the more interesting means of improving efficiency involves more intelligence on the system calling the shots. Many of the appliances in my house have their own control systems built in that are designed to be reliable and robust given an unpredictable deployment environment and unforeseeable usage pattern. Many manufacturers have to build to the lowest common denominator, and while this accommodates the widest demographic of appliance users, it is usually sub-optimal.

For example, I have three refrigeration appliances in my house of six occupants. Two are the "normal" kinds an s with a fridge on the bottom and a freezer on top. Our third is an upright freezer. Two of these have been Venturii'd - with at least a couple of DS18B20 temperature sensors installed within key locations. The third, our main fridge in the kitchen, remains a virgin.

Through my analysis of the temperature data collected from the basement's fridge and freezer, I've discovered a number of interesting things about their usage patterns:

• The basement fridge compressor runs about 50% of the time, quite possibly making it the least efficient of the three refrigerators.
• None of the refrigerators have any means to detect ice buildup in the condenser coils and run a defrost cycle every 24 hours whether it needs to or not.
• Occasionally the doors of said appliances get left open. This has forced me to install door position sensors on the fridge and freezer doors in the basement, with an alarm that sounds if either is left open for more than 60 seconds.

I am fairly confident that if I took over control of the compressor and defrost coil, I could make all three refrigerators operate much more efficiently, taking into account time of day, the number of times the door is opened, the cooling load of its' contents, and the ambient air temperature outside of each appliance. More on that later.
[/list]

49

Energy Management & Monitoring / The Downside To Energy Monitoring and Management

« on: December 05, 2015, 12:54:46 PM »

I've been tracking my utility usage with Venturii for quite a few years now. At first it was merely an amusement to me, but as my budget grew tighter it became an invaluable tool for making effective changes to the way I consume energy. One of the greatest challenges we as consumers face when it comes to our energy consumption is that there are not a lot of convenient ways to monitor this information in a timely manner - most of us have no idea how much energy or water we've used until we get our bill in the mail a month later, and by that time several weeks have already past since that data was collected. This cumulative total every 30 days gives only the broadest glimpse of our utility consumption patterns, and provides almost no information about influences like "How cold was it outside? How many hours of sunshine did I have to compensate with artificial light? How many times and/or how long did I run the stove, dryer, furnace, etc. this month?" Venturii's real-time feedback on your consumption at any given point allows you to walk around your house and turn on or off appliances, lights, or devices and see right then and there how much of a difference it makes to your power consumption.

This kind of feedback can be invaluable for determining where your biggest consumers of electricity, gas and water are around your property, but there is a downside. As we enter the Christmas season, we've set up our Christmas tree. Last year we decided to move away from buying a real tree every year for a number of reasons, not the least of which was the fire hazard the tree posed by the time we actually got to Christmas. Not wanting to decrease the appeal, we splurged a bit and got a very nice fake tree that came pre-lit with 1,300 miniature lights. It looks amazing. However, due to Venturii I know that it draws 470 watts of power, and makes a considerable blip on my power consumption graphs. Therefore, illuminating the Christmas tree is a bittersweet event - it looks beautiful, but I know exactly how much it costs to run.

50

Web-Based User Interface / Report Groups

« on: November 13, 2015, 08:48:34 PM »

One of the things I would like to add to the web based user interface in the reports section is the ability to pre-configure multiple reports (graphs) that can all be run concurrently over the same date / time range. For example, every day I review the power, water and gas consumption of the previous day and/or that day up until [now], the temperature readings around the house & garage, salt levels in my water softener, Solar system power collection and discharge rates, etc. Currently I keep these reports all open in different browser tabs and refresh each one every day. It would be great if I could configure a set of reports that all run at the same time in the same window, showing me all the days' activity in a single report.

51

V_ION / Insteon Module

« on: October 17, 2015, 09:17:11 AM »

Years ago, in my last house, I had purchased and installed a number of X10 switches. They were cheap, and didn't work half bad. I wrote the "ecksten" module which phonetically reads "X10" and had incorporated the ability to turn on or off the X10 devices in my house on a variety of events (alarm system arming, for example, turned off all the lights) and even from the web interface I had developed at the time. However they had two major problems:

• Commands sent to devices did not always execute.
• There was no way to query devices, so manual status changes could not be reflected in the web interface.

I'd even add a third point being that they were very slow to respond when they did. Each command took one full second to execute, when it did. At one point I had the ecksten module send periodic "refresh" commands to the devices, so that if the first command failed the second might succeed. However this meant that manual switch control was virtually impossible (and frustrating) as it would eventually be overridden by whatever state Venturii thought the light should be in.

I began to look for a better system, and found a couple of options. There was actually quite a number of alternate systems for home lighting and appliance control, but the one that won out based on feature set, functionality, price and availability was the Insteon family of products from Smarthome. (www.smarthome.com)

When I moved out of that house, one of the first investments I made in my new home was a complete retrofit of every switch and dimmer in the house with Insteon devices from Smarthome. Although fully functional on their own, the primary purpose of their deployment was the ability to control them from Venturii, which meant writing a whole new module to talk to the devices. That module is the Venturii ION module.

To date it supports all devices in the Switched and Dimmable lighting categories, including linking and un-linking devices. It has the ability (in beta form) to read memory from devices and interpret the link tables. And it can receive commands from devices (status updates) so that Venturii can respond to manual activations of Insteon devices and use them as event generators.

If any or all of that interests you, this is the place to discuss it.

52

Decider / Committed New Revision of Decider & VLib

« on: October 16, 2015, 05:44:35 PM »

I committed a number of updates to the VLIB and Decider repos today, which should help in the following areas:

- Changed the way send() is called, preventing SIGPIPE signals from being emitted. This should let the send() call handle broken pipes by returning 0, which is handled in the code and should trigger a proper shutdown of the socket and a reconnection.
- Changed the way the formula processing function handles registration of interested parties of VINTs, specifically adding a parameter to request a specific trigger type when linking. This was necessary in the case of Torx pegs that were registering themselves as being interested in VINTs used for Conditions and/or Inhibitors. The problem that was happening was that because they were registered as Refresh On Change (the old default) if a CONDI VINT was changed, the peg would get refreshed, causing it to execute it's commands if CONDI was met. In some cases, this would cause a peg to get re-invoked MANY times, even though it should not. Now TORX pegs register themselves with the TRIGGER_NONE type, so that it can check the value of the given VINT in CONDI at the time of peg invocation, if CONDI is met [at that time] the commands will execute, but if not then nothing further will happen until the next scheduled invocation of that peg.
- Tweaked the keepalive parameters in the Websockets part of the code. I looked at including a heartbeat system in websockets to send, say, the current unix timestamp at regular intervals to keep the connection open if there is no VINT updates or ui commands being transferred. Previously it would simply disconnect the idle socket. Even as I write this however, I can see that it did not appear to have the desired effect and the clients still disconnect after a period of inactivity. I guess a proper heartbeat will be required after all, though maybe it can be initiated from the client end. Clients can "request" the current time and Decider will respond, confirming bidirectional communication is functional in the socket.

53

V_ECKSTEN / Legacy X10 Support

« on: October 12, 2015, 05:40:58 PM »

Ecksten was an X10 control module for a much older version of Venturii. It's code base has fallen by the wayside, primarily because I don't have any X10 devices in my house anymore. I've since upgraded to Insteon-based devices, and will never go back. However, if anyone has an interest in using X10 devices, let me know and I'll bring the module back into the current code base and library system.

54

V_DAC / The Venturii Data Acquisition and Control (VDAC) System

« on: October 12, 2015, 05:39:06 PM »

When I started Venturii, I did so not because there weren't other integration systems out there, but because I wanted to see if I could build one myself. I'm pretty proud of what I've accomplished so far, and the one area that probably has the most excitement for me now is this one. Early versions of Venturii were software based solutions that interfaced with hardware made by other companies. In some cases I wrote code based on published APIs, but in some cases I had to debug and distill their communications protocols on my own. This was exciting, challenging, mentally stimulating work and brought with it a greater appreciation for these products, their features, and even in some cases, some un-exploited features. I began to understand elements of the native software, particularly limitations of it, that were actually imposed by the hardware. However, as my interest in the field extends far beyond software, I started to look into the possibility of developing my own hardware for Venturii.

Some of this was out of necessity, for I wanted to connect to sensors that I knew of no other off the shelf hardware platform that integrated with them, some of it was cost driven, and some of it was simply curiosity. Can I do this? To date I've developed two different types of relay control systems, one for traditional "ice-cube" style relays and one for latching relays. Why? Because I had them and had no other way to make use of them. As it is, they now run a whole whack of lights in my garage - just because they can. The NIM-1, discussed elsewhere, will be the next PCB to be tested, but I've also been working on some proto-board-and-wire based prototypes of other VDAC-based devices. It is so much fun for me to create these things that talk to different hardware, adding the ability to collect interesting data into the mix, and also to create circuit boards with specific tasks in mind that hopefully others may find useful as well. Really, I'm building Venturii for me, but if others can use it and learn from it and improve their lives, houses, buildings, surroundings, etc. with it, then I am more than happy with that.

In short, VDAC is the hardware branch of Venturii, native hardware developed specifically for Venturii and designed to talk to a wide variety of sensors, devices, and systems, as well as to control them. It is all open source, the hardware designs are available to download as is the firmware for them. If you can improve on my designs, (and believe me - there is lots of room for improvement!) I welcome all the help anyone is willing to offer, and I hope that many people will find these ideas and creations useful. Of course, to help fund my R&D and coffee, I'm also selling complete units for those who prefer a more turnkey approach. I work in a day job where every major player keeps their cards close to their chests and there is very little to no innovation encouraged where the products we sell are concerned. These large companies have grown their empires by producing proprietary systems that work within their own ecosystems very nicely but generally do not play well with others. And then those companies hold you over the barrel with recurring licensing costs! You buy their products, then you have to pay for licenses to use those products, and have to pay annual license costs to maintain support for those products. I don't want to be like that. I like collaboration and structured community contributions to make the products better. Every time I've installed some part of Venturii in someone else's house, they've come up with uses for it that I would have never thought of, and this has lead to new features, improvements and design changes that have made Venturii even better. I'm really hoping that can be extended to the hardware as well, so let's talk about it here.

55

V_BURG / The Venturii Burg Interface

« on: October 12, 2015, 05:22:02 PM »

Years ago I wrote a module for interfacing with the DSC Maxsys series of intrusion alarms - primarily because I had one in my house. It supported the full command set of the PC4108 (if memory serves) serial interface, providing Venturii with interpretations of all the status codes, ready state, armed/disarmed states, zone states, trouble & supervisory conditions, etc - and allowed arming and disarming of partitions and control of PGM outputs from Venturii also. In fact, my first underground sprinkler control was accomplished with the help of PC4204 relay modules. Funny story, because this was their original task, all four relays were set up on schedules within the Maxsys. Later, when I moved control of the sprinklers onto a different system, I re-purposed one of the relay modules as a keybus expander in the garage. Every night at 4:00 am, the system would go into trouble. A sound sleeper, I never noticed this but my roommate who lived upstairs and slept much closer to a keypad had smashed one right off the wall because it kept driving him nuts every night. As it turned out, the first relay is set up on the expander as a keybus power interrupter to allow com bus resets to take place remotely by pulsing that relay. I had wired the garage combus through relay 1 on the PC4204, but forgot it was still on a schedule. Every night at 4:00 am the 4204 would disconnect the keypad power from the garage keypad, putting the system into trouble and waking my roommate Bo up to an infuriating beep-beep every 20 seconds. Of course, the power would be restored 30 minutes later and I never bothered to check the event logs. It wasn't until I noticed the front keypad all smashed up that I asked him about it and began to investigate.

I've since moved and the code for the module that interacted with the Maxsys has fallen MANY versions of Venturii behind. However, with Mark having a Honeywell alarm in his house and me having a newer DSC PowerSeries model, there is renewed interest in reviving this module and bringing this data back into the system. This time what I'd like to do is create a single module that can talk to as many alarm systems as we can find interfaces for, thus reaching a much greater audience with less coding. Mark's even got an interface module that talks both DSC and Honeywell, changeable by dip switch I believe, which simplifies things even further. It's all time. Right now this is the next module to be (re)written on the road map for Venturii.  Any thoughts, ideas, suggestions, or volunteers to help develop and/or test and/or document this module are welcome.

56

V_ASCII / The Venturii ASCII Module

« on: October 12, 2015, 05:11:53 PM »

Technically, this module is still a concept. The idea being that it will become a standard Venturii module that can connect to any socket or serial port, and provide a bidirectional path for plain text and/or hex slash binary communication to a thing so connected. My first idea for this module is to use it to send PTZ commands to my video surveillance system such as instructing a nearby PTZ camera to go to a specific preset when the doorbell rings or at certain times of day. Of course this would not be limited to PTZ control, in fact it wouldn't even be geared to this task specifically. It could also parse data from other systems, perhaps even house vints and read data from serial or IP streams and convert the values into VINTs. If you have ideas or suggestions or feature requests for such a function, please let me know here.

57

V_LIBS / Venturii Libraries

« on: October 12, 2015, 05:08:33 PM »

The Venturii libraries contain much of the core functions used by most - if not all - of the Venturii modules and Decider.

58

Electronics / Re: AD7705 16-Bit Analog to Digital (ADC) Converter Hanging After Seconds-To-Minutes

« on: October 12, 2015, 11:07:56 AM »

And the morning's results: Success!

The prototype is still pushing data in real time to the LCD and to the Serial Port. (I actually forgot to hit "Post" on this yesterday, but two days in and it is still cranking out values to the LCD and serial port. I'd say that was it, either the Data Ready pin or the spread out wires, or both.)

59

Electronics / Re: AD7705 16-Bit Analog to Digital (ADC) Converter Hanging After Seconds-To-Minutes

« on: October 11, 2015, 01:04:33 AM »

Not one to give up easily, I tested another theory: This time I physically removed the Data Ready pin connection from the AD7705 and the MCU and even reinstated all the LCD and Serial Output code, and so far - it has not locked up once. I am now going to leave it running overnight and see what the result is in the morning. Fingers crossed! (Reason for optimism: It has not run this long without hanging, probably since I added that Data Ready pin. Very odd that doing so would cause so much trouble, especially since it is connected to a pin configured as an input, but there it is - so far, a smoking gun. Of course, I just realized that there is another possibility: Doing so necessitated the use of a different connector type - this time I used a strip of Dupont (?) connectors, and they are all still physically connected together in a ribbon cable. The four pin connectors previously used were not - each wire was free run. I wonder if I wasn't inducing some troubling interference that way, and the shorter, parallel wires in this cable isn't helping solve the problem? Sigh. Either way, it's still working. I need to find out what exactly the cause is before I can truly put this issue to rest, but progress is still progress. Goodnight.

60

Electronics / Re: AD7705 16-Bit Analog to Digital (ADC) Converter Hanging After Seconds-To-Minutes

« on: October 11, 2015, 12:29:17 AM »

I tried a few more things:

• First of all I removed the initialization code for the second channel of the AD7705. I'm not using it and there is nothing hooked up to it's input, so I shouldn't need to do anything on the second channel. Same Result.
• I removed all LCD code from the program; basically it does nothing now since it has no way to output the data, but it still collects it and then clears the counters every 15th pass. Same Result. Interestingly, this time I could not get the green LED to change state by placing an object in front of the infrared beam sensor - it stayed off this time. I suspect there is some conflict between the LCD code or library and the AD7705 code / library. I also noticed that the pin 13 clock LED (onboard LED) was much more smoothly flashing this time - it seems like whenever the LCD display goes to update it pauses the SPI clock just enough to create a noticeable pulse in the clock LED. I don't know what the implications of this are for the rest of the problem, but certainly worth pointing out.
• With the LCD code in place, I tried grounding the Data Ready pin and repeating the IRBS test - with the pin grounded there is no change of state in the LED. Therefore I believe that [somehow] the IRBS or LCD code is affecting the inner workings of the AD7705 board, to the point that we are able to cause it to toggle it's Data Ready pin.

It is getting late and I am going to let this sleep overnight. The more I troubleshoot it the more confused I'm getting. It doesn't seem like this should be possible, and yet - here we are. Hopefully a fresh start tomorrow or another day may help bring new insight to the problem because right now I am stumped!