I am not talking about humans.
But TV-sets might threaten other devices in the smart home; this was a recent puzzle submitted by a blog reader.
Two unrelated devices / services met on the user’s local computer network:
- IP-TV provided by a large German telco.
- a data logger for monitoring the heating system.
This user had one of the solutions in place that I mentioned in my previous post on data logging: The logger BL-NET connects to the controller UVR1611 via CAN bus, and to the computer network via ethernet, and it acts as a ‘CAN-ethernet gateway’ to allow for logging data to database server on the network, hosting the application UVR Data Logger Pro.
The issue: Every time the user turned on the TV, BL-NET suddenly refused to work – communicating its predicament via a red LED. The IP-TV did not use up all the band width; so my suspicion was that the TV (or TV service) sends a network packet that the logger does not like; perhaps a special – sci-fi-like – unicast or broadcast message. Or any of the parties involved does not strictly comply with standards. Or standards might be ambiguous.
It would have been interesting to do network analysis and trace the network traffic and spot that packet of death.The BL-NET product had been superseded by its successor – called C.M.I. – Control and Monitoring Interface – which has better out-of-the box logging, cloud support etc.. The open source UVR Data Logger Pro does not yet speak CMI’s protocol so I understand that BL-NET users do not want to change their solution immediately. But it is unlikely that BL-NET will get firmware updates, and it is very unlikely that a large internet services provider will change its IP-TV communications protocol.
My suggestion was to shield the logger from packets sent by the TV – by tucking BL-NET away in its private subnet – using a spare internet router or the sniffer-router PC I had described in Network Sniffing for Everyone:
The ‘spare’ internet router was placed behind the main internet router, connecting its ‘WAN’ port to the main LAN, and BL-NET was connected to a LAN port of this second router. If the router is a PC with sniffer software this configuration would also allow for researching the evil packet.
This did the trick – BL-NET did not die of TV’s packets anymore!
In order to avoid running yet another box consuming electrical power, one might also…
- add another network interface to the the UVR Data Logger Pro database server and use this one as that router.
- replace the internet router by one that can be configured for more than one virtual LAN (in case the current one does not have this option).
elkemental Force 
Reblogged this on ihatemommybrain and commented:
Bummer, smart home fail
Excellent solution. It will provide a permanent solution that never needs tinkering. I believe this type of problem is one that will become increasingly prevalent. Its also a good reason why consumers should always buy an access point with a multiband radio ☺
True – I have also fixed some weird WLAN connections issues with a two-band radio router.
I can’t be tested in this case as the devices in question needed wired connections – but it would be interesting to investigate if it would helps. I think it depends on where in the protocol stack the clash happens: Different bands separate connections from the devices to the router at the lower layers, but the devices’ communications will still ‘meet’ at the upper protocol layers in the local subnet. I hope normal routers will provide virtual LANs in he future!
Indeed–the best solution of all. Keep ’em separate ’til the end :-) On that track, though, here’s a question: is the data logger using a UDP protocol, maybe (and if, so, why since there’s no no conceivable reason why you’d need that much speed to just send information about a heating system? I have yet to see that type of “interference” from TCP packets. Of, course, on that note and it is TCP then why, on earth, would any maker use anything other than plain text for the transmission data. It’s just sending sensor readings, right?
It is TCP and it does not need much speed and bandwidth as it is actually not intended to be used as a real-time logging protocol (in my opinon): It was designed as the protocol to be used on a PC running Windows and a software (provided for free by the vendor) that will fetch log files stored on the logger. You would fetch the log files once every few days. The software can also configure the logger and tell it to keep or delete the logged data – so the application protocol is more than just reading data. It is rather sort of a file transfer protocol, so a binary transmission of the file contents makes sense to me. The successor of this logger by the same vendor uses HTTP to fetch the log files.
The open source logging solution (in place in this case) uses the device more like a real-time logger, by using the same protocol but reading off data (fetching mini-logfiles) more often – so that you don’t have to rely on the limited storage space of the data logger device but but log to your own database in real-time instead.
Ah, the Internet Of Things is going to be a wonder of clashing bandwidth and mutually angry appliances, isn’t it?
At least many protocol converters / gateways and the like will be required in case on user does not buy anything from one vendor and/or has it all installed at the same time by a single contractor.