Recent Posts

Pages: 1 ... 4 5 [6] 7 8 9
51
V_ION / Insteon Module
« Last post by Cube 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
« Last post by Cube 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
« Last post by Cube 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
« Last post by Cube 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
« Last post by Cube 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
« Last post by Cube 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
« Last post by Cube 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
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
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
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!
Pages: 1 ... 4 5 [6] 7 8 9