Project Ingress 2.1

September 29th, 2015

{This is a Content Place Holder}

Project Ingress has been up and running for about 3-4 months now, and has been fairly successful. The hardware setup has gone through a number of variations and revisions, but all have basically come back to the same design. Some of the electronic components are required to be on a short tether, which makes it difficult to manage.

In the last few weeks, I have rewritten much of the code, using a more modular approach. Doing this, I have also added a lot more functionality. I am hoping to start field testing the new version of the software in the next few days.

While working on the new software, I came up with an idea on how to shift the hardware components around. Some of the parts will need to be fabricated on a 3D printer. This will have to be a v3.0 upgrade at a later date.

I hope to start getting pictures and details posted soon.

 

Pro Trinket and RF24L01 Transceiver RF Module

September 29th, 2015

In this project, we took a Arduino Pro Trinket, RF24L01 2.4G Transceiver RF module, MCP9808 Temperature sensor, and a voltage regulator. Our module broadcasts temperature values wirelessly over the 2.4GHz band. This data is received by another RF module which is connected to a workstation via a USB connection. Running on this workstation is a custom application which takes the data and allows us to manage it. At this time, the app forwards the data off to a SQL server, which runs off a Raspberry Pi. Also running on the Pi is a web server. Connecting to the web page, python code pulls data out of the SQL database and displays the temperature values via graphs. Currently there are five zones being monitored at 5 minute intervals. This process has been running for just over 9 months so far. Eventually this data can be pooled with the home power meter readings.

 

This is the proto-board with the basic components soldered in place. In order to be able to reuse our components, sockets were added. Most of our components run off 5v, however our RF module requires 3.3 volts. A voltage regulator was added. We have our 5-12 volt rails on one side, and our 3.3 volt rails on the other.

TrinkedProRF_01

 

Here we see all the components finally in place. While developing the code, I came across a really good timer module. Making use of this, I added some LED’s that trigger off 1, 10, and 60 second intervals. Nice thing about the lights, we can see that the board is still functioning.

TrinkedProRF_02

 

Here we can see what the back of the proto-board looks like. Components were arranged in order to help keep the wiring better organized.

TrinkedProRF_03

 

With the proto-boards, all the columns are connected together. In order to add multiple components to the same row and keep them independent/isolated from each other, the trace lines had to be cut.

TrinkedProRF_04

 

This is a sample packet that is passed from the RF module.

TrinkedProRF_05

 

Here we can see versions of the module. The one at the top is the finished version, while the one on the bottom is the test board that was used to test everything before making things permanent. The bottom version also contains the setup that we can use when running off a battery. In this setup, the top board is sending its data via RF  to the bottom board.

TrinkedProRF_06

 

The following is a windows application that I put together. The application currently is limited to only receive data from up to 6 separate RF modules. In the design, there is a master RF module which takes readings and passes them to the workstation via a USB connection. This RF module (Master) is also programmed to look for any other RF modules (Child) and pass its data on to the workstation. We can handle up to 128 separate RF modules sending information. Our limitation right now is the application.

Here we can see the different zones we are getting data for. We receive data from the different modules once every minute. Our application will actually push all the data it receives once every 5 minutes to a SQL database which runs on a Raspberry Pi. The application also has the ability to send SMS notifications to a pre-determined phone number. Currently its setup to send any error notifications that may occur.

TrinkedProRF_07

 

On our Raspberry Pi, we also run a small web server. The web code there queries our SQL server and pulls back the data, displaying each zone as a 6 hour and 24 hour graph.

TrinkedProRF_08

Adding an Attribute to the CMDB via a CMDB Driver Script

April 3rd, 2014

There are a number of ways to create an attribute in the CMDB. You could use the BMC Atrium Core Console, Remedy API, or the CMDBDriver.

The BMC Atrium Core Console offers a nice GUI interface, and is fairly slick when used via the mid-tier. I have noticed some issues using the mid-tier version vs the UserTool version. One issue that I’ve noticed is that sometimes custom fields do not show up when your viewing the classes. When viewed from the UserTool, everything is there. Another issue I have noticed is that the Menu Style field shows different results when compaired to what one see’s in the UserTool.

The Remedy API is a very powerfull feature, if used correctly, and you understand what your doing. I have built everything from forms, fields, active links, filters, and guides with the API and really, one takes for granted what the GUI does for you.

But the topic is the CMDBDriver tool. This is not a user friendly tool, but once you understand it, its great for automating alot of your work.

The one feature is the “execute” command. This allows you to execute a driver script that is basically a list of commands (like a macro) that you want the driver to execute. The following text is what is used to create a selection field, with 3 entries, on the BMC_Application class:

ca
BMC.CORE
BMC_Application
CUS_BusinessGroup
OS-0050368f00f39DRrUwYP1cqw21KL
6
900100102
2
2
3
Corporate Group
12100
Customer Group
12200
Enterprise Group
12300
F
1
8
4
CUS.CUSTOM
0

These lines would sit in a text file, and the driver would execute the contents. The first line is the “CA” command which stands for Create Attribute. The following lines would be the supplied input for the process of manually creating an attribute.

The power of this feature is that you could maintain a number of these commands in the text file, allowing you to create as many fields, on as many forms as you like. For example, when I build out a new server environment, I can execute just one file that will add every custom field we added to the CMDB, bringing it upto speed with our existing environments.

CMDBDriver - Start Up

CMDBDriver – Start Up

 The next step is to enter the “init” command. This initizlizes the session, closing off any other session that you may have been already logged into. This is the first step that you must do when first opening the application. The next step is to enter the “log” command. Here you are logging in with your UserID, Password, and Server Name. Finally, if you are using a port number to connect to your server, enter the “ssp” command. This allows you to enter your TCP port number.
Initialization and Login

Initialization and Login

The next step is to issue the “ex” command. This will prompt you for the command/driver file to load. Enter in the full path and filename. No need to enclose everything in quotes, as spaces dont matter.

Execute Command

Execute Command

This is the part of the process that gets cluttered, and leaving you wondering whats going on. As the CMDBdriver executes the script, prompts for data are appearing on the screen. Normally you would manually enter the values, but our command file is supplying the data for us. I would have been nice if the values were actually displayed as the system exectued the file. Depending on how many attributes, which class your hitting, and the amount of data in your CMDB, this could take a few seconds or minutes to complete.

If you have multiple attributes being created, this screen will repeat the the cluttered block for each one. Once done, you should finally see the Command prompt come back.

Execution of the command file

Execution of the command file

Over the years, dealing with problem tickets with BMC Support and talking with the application engineers, they all have said that they use the CMDBDriver for most of the work that they do. When you use the Atrium Core/Class Manager to add attributes, the CMDBDriver is actually being called in the background to do the work. It pulls its information from the OBJSTR:Class form (these are your Pending records). Once the driver completes the task, the record in the OBJSTR:Pending form is removed.

One nice thing about the CMDBDriver is that if something goes wrong, it tells your right away. If something goes wrong using the AtriumCore/ClassManager, you have to go in and start deleting records in various forms.

One last helpful hint if AtriumCore/ClassManager does not appear to be completing the building of your new field, you can grab the ‘Pending ID’ and from within the CMDBDriver, issue the “sync” command, which will prompt you for the Pending ID. This will force the attribute to complete for you, and the matching record in the OBJSTR:Pending form will disapear (As long as there are no errors in your system, but thats another issue to resolve). Note that the ‘Pending ID’ is not visible on the form, but you have to export the data, or manually type it out from the report option. On most of my sites, we have made this field visible (read only) so its easy to grab.