Monthly Archives: June 2011

Network monitoring

  By Robert Hekkers | June 26, 2011 - 22:17 |
Comments Off

The list of  devices in our house that need an Ethernet connection in order to work, just keeps on growing and growing. There was a time (some years ago) where I knew the IP address of each device by heart, but I gave up on that some time ago.. currently, my local DNS contains over 40 hostnames; just try to remember those (all of them!).

The number of switches keeps increasing too; currently I have 5 of them. And what is the most likely cause of a network going down? Right, a switch that stops working – this has happened to me twice now; and at both incidents the power adapter was the cause. So it seemed like a good idea to start tracking all those network attached devices, so that in the case of a dis-functional network it would become much easier to locate the root of the problem; at least, I hope so ;-)

Let’s start pinging all those devices! I found a nice Delphi unit that uses the standard Windows icmp.dll and the ICMPSendEcho function to ping an IP address and created an interface that would take care of periodically pinging all the Ethernet enabled devices and interfaces I had defined in my database and which were capable of replying to a ping.

The result can be seen here; a very basic page where I can see which Ethernet devices are on or off. Although ping is a very basic tool in itself, combined with a Domotica system you can do a lot of things with the information once you start logging them. I know the power consumption of most of the devices in our house, so now that I know when they’re being used or not, I can estimate their power consumption for example. Or I can issue an alert on the User Interfaces when the printer is on for more than an hour, cause in daily practice only a few sheets are printed and someone forgets to switch the printer off afterwards. Or I can send myself an SMS when a critical device stops responding to a ping. Or …

All new opportunities!

Building the doorbell controller

  By Robert Hekkers | June 23, 2011 - 20:49 |
1 Comment

2 days ago the hardware for the doorbell controller arrived; a JeeNode v6, a Carrier Board, an Ether Card and a Utility Plug. After building the first 3 items on the day they arrived, I was ready to do some tests yesterday. I installed the latest Arduino IDE, the latest RF12, Ports and Ether Card library and hooked up the JeeNode to a USB BUB. I saw the RF12demo sketch appearing in the Serial Monitor; so far so good.

Let’s see if there’s an example sketch in the JeeLabs Ether Card Libary I can quickly modify for testing; yep, the getStaticIP sketch looks OK; I changed some IP addresses, the page to request on my web server and the request interval. I pushed a patch cable into the RJ45 plug, uploaded the sketch and bingo!

Ready! Hmm, no, not really. It all seemed to work perfectly, but after a while I saw strange replies in the Serial Monitor window and I could tell they didn’t belong there. These replies came at times where there hadn’t been a request for several seconds, so where was this reply coming from? I searched the code but couldn’t find out what the status code 3 meant that was returned with these strange replies. Hmm, I don’t like this. Just ignoring those strange replies was easy to do but it just didn’t feel right. There had to be something wrong; I mean, have you ever heard of a garbage filter on a NIC? Me neither.

I decided to dig a little bit deeper. The next morning, while on my way to the office, it hit me: the HTTP 1.1 protocol, doesn’t it use persistent connections by default? And does the connection get closed by either side after the reply has arrived? I checked RFC 2616 and I was right, so the first thing I did when I came home was checking my IIS logs and found the evidence for open connections being closed by IIS after a certain idle period:

192.168.10.203 3031 192.168.10.13 80 - - - - - Timer_ConnectionIdle

That could very well be the cause of those garbage replies I saw on the JeeNode!

Looking at the sketch I saw that the request didn’t contain a Connection:close header line. So my server did not close the connection.. after changing the request to HTTP 1.0, the behavior of the server changed and it closed the connection after sending the reply. This was also visible by the extra header line the server added to the reply: Connection:close. And guess what: the garbage replies no longer appeared and everything’s fine now. Now that traffic between server and JeeNode was clean, I could start working on the enclosure.

I disconnected the USB BUB, grabbed an enclosure and started cutting out holes for the DC jack and the RJ45 plug:

Doorbell controller in enclosureDoorbell controller in enclosure

 

 

 

 

 

 

With the enclosure almost finished I connected a 5V power adapter to the DC jack, put the patch cable back in and I saw the requests arriving at my server again. Perfect!

Doorbell controllerDoorbell controller: case closed

Finishing the Doorbell

  By Robert Hekkers | June 19, 2011 - 22:56 |
Comments Off

 

Today I finished modifying the doorbell with which I started yesterday. I drilled a 4.5 mm hole through the back of the doorbell and led a solid core CAT5 cable through that hole. This cable will be used to connect the doorbell switch and the 2 LEDs (a white and blue one) to the Jeenode that will be placed in the fuse box which is only 2 meters away. The legs of the LED were bent sideways right there where they come out of the LED housing and these legs were temporarily glued to the doorbell housing to secure the position of the LED for easy soldering. You can still see some residue of the glue (the white blur on the housing surface) where the legs of the right LED touch the doorbell housing.

Finishing the hardwareFinishing the hardware

 

 

 

 

 

 

To get a good insulation from the outside world, I pushed the cable through the hole, put hot glue on it and pulled the cable back  a few millimeters; this should suffice for proper insulation. After the wires were cut to the right length and soldered to the legs of the LEDs, it was time to check if everything was working. So I put the 2 halves of the doorbell housing on each other, pressed them firmly, and put the other side of the wire on a breadboard. With a 5V power supply, two 330 Ω resistors and a multimeter I convinced myself that everything was OK.

BTW, it’s a good thing I didn’t choose red as one of the colors for the LEDs; otherwise, a visitor might think he’s being held at gunpoint by a sniper with laser sight :-) In other words, the LEDs are a bit too bright, so I think I’ll use a higher resistor value in the final version – that’s why I left the resistors out of the housing in the first place, cause I was anticipating “tuning” issues like this.

Well, now that I have verified that the doorbell is working OK, I can move on to the next step: the JeeNode, some more hardware and the software that goes with it!

 

A new doorbell

  By Robert Hekkers | June 19, 2011 - 16:08 |
2 Comments

One of the things I never liked, was our doorbell. You’ve probably seen or used them, those mostly black plastic boxes with some pieces of copper strips inside; the mechanism relies on those 2 copper spring-like strips to make contact when the button is pressed and return to their old position when the button is released. However, more than once it has happened that if someone pushes the button too hard, the button doesn’t work that well anymore because the strips are bent. Time to do something about this annoying issue and solve this once and for all.

So here’s the most important requirement: the new doorbell should always work. Besides that, I wanted the doorbell to have a distinctive ‘click’ as physical feedback and if possible, also a visible feedback for the person standing in front of our door pushing that doorbell button. Last but not least, the visitor should be able to find the doorbell while standing in front of the door while it’s dark outside. A white LEDs should be able to do just that.

I bought a wireless doorbell once, thinking I could remove the wireless part and just use it as a simple switch . But I was wrong; the button and wireless part were too much integrated for me to do something useful with the PCB that was inside. This wireless doorbell cost me about 30 euro, the looks were OK and I didn’t want it to end up on the shelf with all the rest of the things I’ve bought but never used. Sounds like a good opportunity for some DIY ;-)

I removed the PCB from the doorbell, glued a piece of experimenting board into the doorbell and soldered a PCB switch on top of the board:

New Doorbell

Fits perfectly. With this switch you get instant feedback on whether the switch sensed your push because of the audible and tactile click, you can both hear and feel it very well. As visible feedback for pressing the button I decided to use a blue 3mm LED. This LED should cooperate with the white one, which should take care of night visibility: resulting in a blue indicator above the button when it’s pushed, and a white indicator while it’s dark outside.

While working on the new interior of the doorbell, I decided to use a JeeNode with EtherCard to control it all, thereby creating my own Ethernet-enabled doorbell. Why? Because I can! :-)

To be continued.

 

Keeping AV power consumption acceptable

  By Robert Hekkers | June 15, 2011 - 15:41 |
1 Comment

After the first night with Network control enabled on my new Onkyo, it was clear that something had happened to the power usage; it was much too high compared to the usual power usage during the night. I didn’t want to postpone the power measurements any longer, cause the power usage increase was too much; I had to know where this was coming from. So I did some tests today regarding power usage of my new Onky TX-NR709… well, it was worth it! Here are some numbers:

  • Receiver on, watching TV: 42-43 W
  • Receiver on, listening to the Tuner: 43-44 W

Ok, I can live with that. Now let’s see what the power consumption is when I switch the receiver to standby: 38W. WHAT? WATT?? Yep, thirty-eight. This is ridiculous, this can’t be true. Standby usage as stated in the manual is 0.3W; but as I already mentioned earlier, the term “slightly” with regard to power consumption of a device capable of consuming 730W doesn’t say a thing. Apparently, the guys at Onkyo think that an increase of 5% of 730W can be called slightly; yeah right, think again. It’s a lot!

So, what can be done to fix this? Cause this is not acceptable of course. I’m not going to accept a new device which will add 38W to my power consumption 24/7, no way! There are a few things to explore; I changed the factory settings at some points of which I knew they would “slightly” increase standby power consumption (the word “slightly” is getting a whole new meaning for me now, thanks Onkyo …), so I decided to rollback those changes and see what the effects would be.

The changes I made of which I knew they would influence standby power consumption were HDMI Through mode and Network Control.

HDMI Through mode enables (regardless of  the AV receiver being on or in standby mode) to pass both audio and video stream from a HDMI input through to the TV. In other words: you can pass your cable STB output through to the TV, even when the Receiver is in standby mode.

Network Control mode enables or disables control over the network (duh).

Being an optimist by nature, my first thoughts were that this HDMI Through function was the biggest contributor to this huge standby power consumption, so I switched it off again. No change.. Standby power usage  was still 38W. So I switched off Network Control as well. Bingo! 0.0W, that’s the way I want it. Turning back on the HDMI Through function made the power consumption increase to the unacceptable level of 38W again.

So, what’s the real benefit of Network Control over RS-232? Nothing, zero, nada; or better, it makes the receiver perform worse in my opinion, the effect on standby power consumption is ridiculously high. Let’s assume the  receiver will be used 8 hours per day, this standby power consumption of 38W would mean 38x16x365= 222 kWh per year … that’s about the same amount our washing machine uses during a year ! Need I say more?

I think Onkyo should do a Search&Replace on the text of their manuals and replace the word “slightly” with “considerably” or “unacceptable” or something similar…

In the mean time, I’m preparing a switch to RS-232 control!

Controlling the AV Receiver

  By Robert Hekkers | June 13, 2011 - 20:19 |
1 Comment

Being able to control my new media player is nice, but of no use at all if the AV Receiver the player is connected to (along with a Cable STB and a Playstation) cannot be controlled. I wanted to have the same wired control for my AV Receiver as I have for my media player and searched the net for a suitable model with all the right specs. Both Denon and Onkyo (and probably more, but those are my favorite brands) have the ability for controlling some of their Receiver models with  a RS-232 port and both have  reasonably well documented proprietary protocols.

The new Onkyo TX-NR709 I bought recently is also equipped with a RS-232 port (what a surprise :-) ), so this makes controlling the whole set of A/V equipment complete: TV, Dune media player, AV Receiver, Cable STB are all under control of my Domotica system; either wired or by IR (IrTrans). After I bought the receiver, I found out that the Onkyo is not only controllable by means of the Serial RS232 port, but that the Ethernet connection can be used for this purpose as well. The Serial protocol (called ISCP) and the Ethernet version (eISCP) look very much alike, in a way that it should be possible to support both protocols in one go without much extra work. The Ethernet version has some extra header bytes, a data length and a version byte added to the ISCP Message, that’s all; the ISCP message stays the same.

But why should I want to support both? Well, it seems not all receivers are that good at keeping power consumption at an acceptable level when network control is enabled. The Onkyo NR709 user manual says: “enabling network control will slightly increase power consumption in Standby mode“; right, we’ll see what “slightly” means, considering this receiver can consume 570W. If the difference between with or without network control is too big for my taste, I’ll go for RS-232 (only if this can compensate for the extra Serial Ethernet Server running 24/7  ;-)) I have all of my power usage monitors in use while I’m writing this, so I’ll have to test this power consumption issue later; for now, it won’t hinder development and testing of the interface; I can make the choice between RS-232 and Ethernet later.

The nice thing about the (e)ISCP Protocol is that there are different ways to control the Receiver; for instance, the Muting Command has 3 values with which you can control it: on, off and toggle. Why’s that so convenient? Because with this, there’s no need to track the receivers Muting state in my own Domotica system.  Without the toggle option built into the protocol, I would have to track Muting state if I would like to have a single “Mute” button for a GUI, cause I (read: my system) don’t know what the user wants to do; mute on or off? I’ll have to know the current mute state to send the right mute command…

With the on, off and toggle options I can switch muting on in case of an incoming phone call, off again at the end of that phone call, but also create that single mute button on the GUI as well, all without the need for tracking everything I want to control. Of course, this is not the complete story behind something ‘simple’ as controlling mute; it’s very easy to come up with scenarios where things can still go wrong… there’s always that user, constantly interfering and overriding things ;-)

After a few hours of defining all the commands that are supported by the (e)ISCP protocol, I could do my first tests today. I started with testing the Master Volume Command (“MVL”). Nothing really spectacular actually; I pushed a button and the Master Volume went up; pushing another button made it go down again, just as I expected. No, the really cool stuff happened when I went to the living room and manually turned the Master Volume knob; I saw incoming eISCP packets containing the new, manually set Master Volume! Wow, this is real 2-way communication! Nice surprise, I missed that one :-)

This means I’ll be informed of everything that’s happening without the need for polling; this is what I really wanted but didn’t expect to get! Now, when someone selects the tuner on the Receiver (no matter how), I can switch off those devices which are not needed for listening to the radio – the TV, the Dune and the Cable STB. Or switch off the Dune media player when watching cable TV. Ow yeah :-)

Darn, I don’t have discrete IR codes for my TV; no wait, haha, I don’t need those discrete codes anymore! Since the TV is Ethernet connected, I can ping it (another small project I’m working on) so I do know whether the TV is on or off…

Long live integration!

 

Controlling A/V hardware

  By Robert Hekkers | June 12, 2011 - 15:57 |
1 Comment

Last year we replaced our ‘old’ Loewe CRT TV by a new LCD HD model from Samsung. Bigger LCD screen, lots of pixels, (HDMI) inputs, Ethernet connection, etc.

I’ve also been using a Pinnacle Showcenter 1000 (yeah, it’s really old :-) as media player for years, but the new Samsung TV didn’t support the video output very well, so the Showcenter couldn’t be used anymore and I had to live with the DLNA capabilites of the Samsung. After living a year without a real media player in the living room, it was time to do something about that. And while at it, why not take a closer look at the rest of the A/V equipment? Cause I’ve never been really 100% satisfied with the current Home Theatre system – the DVD player only accepted DVDs after switching the thing completely off and sometimes 1 or 2 speakers just stopped working. You know what…it’s time to replace all the A/V hardware! (except for the TV)

Since I’m always looking for a way to control stuff from my Domotica system, I had an important extra requirement: being able to control (and monitor) my A/V equipment by means of Ethernet, RS232 or anything else I can handle.

The first thing I selected was the HDI Dune HD Max media player. The good reviews and form factor were the decisive issues on which this choice is based. And guess what… the (beta 1 GBps) Ethernet connection can not only be used to stream media to the player or download new firmware, but also to control the player – cool!

On the HDI website I found a document describing how the Dune can be controlled with HTTP calls. With these HTTP calls all of the remote buttons can be ‘simulated’ and there are some more HTTP calls specifically to stop/start and pause media. This is fun!

I started up my Delphi IDE, created a new Device class to see if I could make my Dune respond to my commands. I decided to test the Eject button, like this:

http://HDMAX/cgi-bin/do?cmd=ir_code&ir_code=EF10BF00

I let the HTTP call fire, walked to the living room and – yes, the drive tray was open! Well, when all the remote buttons can be emulated, it’s just a matter of time before I can control the Dune with my Pronto, Touchscreen … well, anything I guess.

But there’s more…

The HTTP response contains some interesting information regarding the player state; things like command status, player state, playback speed, duration & position (depending on the state the Dune is in) are returned:

I wish all things were as easy as with this HDI Dune! :-)
Next item on the list: a new A/V Receiver.

Foscam FI8918W

  By Robert Hekkers | June 12, 2011 - 15:21 |
2 Comments

I have a webcam page on my website since 2007 or so; the first camera I used for this page was a Sony EVI-D30 PTZ camera with a Convision V200 video server. You could even move the camera around but this was rarely used and the Convision wasn’t really efficient, it got really hot so I wanted something else instead; so I bought a Axis 206 Network camera and used that one for a couple of years. A couple of months ago the Axis stopped working, so I had to find a new camera. The requirements for this new camera were not that hard, cause all this camera had to be able to do was showing a LED bar reasonably well, it should have wired Ethernet and the housing should not be too big. And of course it should support all browsers, with or without a little ‘help’.

I decided to test a Foscam FI8918W. Some highlights:

  • Image Sensor: 1/4″ Color CMOS
  • Image res. 640 x 480 Pixels
  • Minimum Illumination: 0.5 Lux
  • Built-in Microphone and Speaker
  • Resolution and fps: 15 fps @ 640×480 (VGA), 30 fps @ 320×240 (QVGA)
  • Ethernet: 10/100Mbps RJ-45
  • Wireless: IEEE 802.11b/g, WEP & WPA WPA2
  • Protocols: HTTP,FTP,SMTP,DHCP,PPPoE,DDNS,UPnP
  • Pan/Tilt Angle: 300° /120°
  • 11 IR LEDs, night visibility up to 8 meters
  • Dimension: 110 x 100 x 108 mm
  • Net Weight: 418 gr.
  • Power Supply: DC 5V
  • Power Consumption: 5 W
  • Price: <100 euro.

The time between unpacking and actually using this camera is very short; you should be able to get it up and running in a matter of minutes. Connect the Ethernet cable, start the IP Camera tool that’s on the setup CD, double-click on the camera found and you’ll find the login page:

Device configuration is very straightforward; all settings are categorized into 15 pages for Network settings, DDNS, Wireless, Mail, FTP, PTZ etc. so it’s very easy to find the setting you’re looking for; and it’s all there – all the settings you may expect to be on a camera in this price range. Some pages (FTP, email) have their own test buttons, so you can instantly test if your settings are correct.

I removed the old Axis 206, assigned the IP address of the old Axis to the Foscam , mounted the camera to the ceiling (upside down),  and in 15 minutes I was good to go :-)

Since the webcam page worked with a Java applet, I had to change that page a bit. But with a SDK manual I found, this change was very easy to do; all I needed was a <img> tag in the page, like this:

<img src="http://cam2.hekkers.net/videostream.cgi?user=guest&pwd=guest" />

This was enough to support all non-IE browsers. However, there are still some people who are using IE and I didn’t want to burden them with downloading an ActiveX file to be able to view the camera image. I mean, would you download an ActiveX from an unknown, nerdy website about Domotica? I wouldn’t ;-) So I used a few lines of Javascript to create something acceptable:

<img src="http://cam2.hekkers.net/snapshot.jpg?user=guest&pwd=guest"
         name="foscam" id="foscam" width="320" height="240" onload='reload()'>

This <img> tag and the Javescript below creates a constantly reloading snapshot on the webcam page:

Add some browser detection to the page so that each browser (IE vs. non-IE) gets its own ‘version’ of the page and everybody can view my new Foscam camera without the need for ActiveX! And that’s exactly what I wanted.

Conclusion: this new Foscam camera gives excellent value for money, provides a decent image, has all the features you can expect considering the price (of which many aren’t even used by me…) and certainly worth considering when you’re looking for a new webcam.

Another thing worth mentioning is the good support I got from the people at ipcam-shop. Although I haven’t bought any camera there yet, the quick response to my questions was astonishing; these people still know what customer care means. I know where I will buy my next cameras, that’s for sure!