Twitter

by acls us

Using InfluxDB and Grafana to monitor TFL Underground Rail Stations

TFLTransport for London (TFL) publishes a lot of Open Data for Public consumption about the status of the London Underground, in real time. This data is updated every 30 seconds in XML format and is mostly documented.

As a proof of concept I wanted to setup InfluxDB to hold the status of the Underground Stations and present the results on a Grafana Dashboard.

The first step was getting hold of the XML data. Unfortunately the SDK does not say what the Domain is to get the XML from. A little Googling allowed me to find the XML I needed here.

The next step was to extract the data needed from the XML. I wanted to get the name of the TFL Underground Station, It's status and a description of any issues. A simple PHP script was used to get this data, format it and use an Influx file import to add the data to an Influx Database. The PHP script is runs under cron every 60 seconds.

Finally I created a simple Grafana Dashboard using "Table Panel" panels to show the data.

Grafana

Using Zabbix and Grafana to monitor TFL Underground Rail Lines

TFLTransport for London (TFL) publishes a lot of Open Data for Public consumption about the status of the London Underground, in real time. This data is updated every 30 seconds in XML format and is mostly documented.

As a proof of concept I wanted to setup Zabbix to monitor the status of the Underground Lines and present the results on a Grafana Dashboard.

The first step was getting hold of the XML data. Unfortunately the SDK does not say what the Domain is to get the XML from. A little Googling allowed me to find the XML I needed here.

The next step was to extract the data needed from the XML. I wanted to get the name of the TFL Underground Line, It's status and a description of any issues. A simple PHP script was used to get this data, format it and use the Zabbix Sender (zabbix_sender) to post it into a Zabbix Server. I organised the Zabbix data using a Zabbix host for each one of the Lines with a few Zabbix items (which must be created as "Zabbix trapper" item type) to hold the data. The PHP script is run on a Zabbix Server (just for convenience really) under cron every 60 seconds.

Finally I created a simple Grafana Dashboard using "Status Panel" panels to show the data.

Dashboard

Are Ubiquiti actively blocking installation of Third Party Firmware?

In my particular case this question relates the UniFi AP v2 but has more general implications.

One would imagine this to be a simple question to answer with a yes or no answer but not for Ubiquiti it seems.

I have been asking this question of Ubiquiti for about a month now after having problems loading OpenWRT 15.05.1 into a number of UniFi AP v2 units. The answers from Level 1 support (via their forums) has been, "It shouldn't be blocked" (hoping for a Yes or No), "It's ok in the latest release" (it wasn't), "I'll have to check with Development" (still waiting for that), "We don't support Third Party Firmware" (wasn't asking for support) or (the most honest) "I don't know". So I pressed for an answer, they escalated it to the next level but were very vague about what that meant. Oh and it seems Level 1 support at Ubiquiti have no SLA what so ever with the team they escalate to. They also have no way to communicate with them after an escalation. So the question has gone some where in Ubiquiti to be answered at some unknown time.

My own feeling is that they are avoiding answering the question as they took the excuse of the FCC rules relating to unauthorised changes to Wireless parameters that could be part of Third Party Firmware, to do this. Of course the FCC rules only applied to 5Ghz not 2.4Ghz Wireless and, as the FCC have stated, was not intended to be used as a reason for blocking Third Party Firmware. TP-Link got caught up in this too. So they cant say they are blocking.

I also think they are actively blocking. Firmware Images for the UniFi AP v2 have a different device type in their header but this is easy to cater for by either making changes in the OpenWRT firmware builder to generate a correct header (sorry not going to go into derail on that here) or by using a binary editor to change it manually. The real issue is that the Ubiquiti Firmware images have a new RSA signature section at the end. The U-Boot loader, already on the device and included in Ubiquiti Firmware updates, checks the signature and rejects images that don't have it, making TFTP updates not work. fwupdate.real used to do upgrades via the command line, also checks and rejects images without the signature giving the "Invalid FW Part 3 MAGIC 'END.'" message.