I was looking through the analytics on AppConnect this morning and spotted this:
Roomr had 102 downloads in one day. What the hell caused that I wonder?
I was looking through the analytics on AppConnect this morning and spotted this:
Roomr had 102 downloads in one day. What the hell caused that I wonder?
Wanted to work on my garden LED lighting project weekend. Unfortunately, I may have made a slight miscalculation with my measurements…
I placed an other with RS for a replacement box, this time a little wider! If all else fails I can always take the circuit board out of the case and place it directly in the junction box, but I’d rather keep it housed.
I did manage to test it out though and the lighting is effective enough.
Maybe next weekend?
Having failed to read the warning regarding neutral wires, my attempt at using a Sonoff T1 Smart Switch to control my porch light went down in flames. My plan B was to try using a Sonoff Basic WiFi Smart Switch to perform the same job. My plan to put the relay between the ceiling rose and the bulb holder. It wouldn’t be pretty, but the aim was to test utility before spending £££ on proper smart switches etc.
As you can see, my porch light is pretty standard.
First step, I turned off the power at the fuse box. Can’t stress this one enough. Don’t go near any mains electricity until you’ve isolated the power. Don’t just turn off the light switch!! I gathered all the parts and tools I’d need.
I then disconnected the light bulb holder, removing the little red plastic thing and the curved lid.
Using a short piece of flex, I connected the Smart Switch directly to the light bulb holder.
Next, I connected the Smart Switch to the cable hanging from the ceiling!
As it was hanging a bit low in the porch now, I created a loop and used two tie-wraps to hold it in place.
As it was all hooked up, I turned the power back on. Nothing started to smoke, so I knew I’d gotten that part done okay. The green light appeared on the relay and I started the pairing process. This involved holding down a black switch on the relay for a few seconds until the green light started flashing quickly.
I then launched the EWeLink app and hit the Add Device button. The process is straight forward. When you push the button down on the device, it creates its own WiFi network. You then connect to that WiFi network, enter details of your own WiFi network (SSID and password) and it then connects itself to your EWe account.
Following the instructions, I found the Smart Switch’s WiFi point and connected.
Once connected, the pairing process starts.
After a few seconds, you’ll be able to control the device! I tapped on the power and, eh voila, the light came on.
As part of my learning and experimentation with Homekit and home automation, I recently picked up some Sonoff Basic Smart Switches. I’ve successfully installed one them outside, controlling a few metres of LED strip lighting.
It’s pretty novel to turn it on and off via Alexa or from my iPhone, but to be honest, it’s not very practical. Flicking a switch is just than saying “Alexa, <pause> turn on the side alley light”. Pause. <click>. “Ok”. Whilst voice control gives you flexibility (hands full etc.), 99% of the time the light switch is the king.
In my quest to check whether the smart home is practical, I wanted to try out a proper, in the wall, smart switch. I’d found a few companies such as Den Automation (who I’ve actually invested in, but who’s stuff isn’t on sale yet) and Lightwave RF, who make normal looking switches (normal from a UK style). The downside is that this stuff is expensive.
Taking Lightwave for example, a single Lightwave switch will run you £60. They also require a hub or bridge, which means an additional outlay of over £120 before you can even use the switch! Spending the bones of £200 just to check whether a smart switch is useful or useless is a bit much. I needed something cheaper to get me started!
Enter the Sonoff T1 WiFi lightswitch
I dropped £31 and bought two switches, a two-gang and a three-gang. Aesthetically, I don’t find them appealing since they are just white and I hate touch buttons, preferring something that actually clicks.
I digress. The first step with any new light switch is to actually install it in your house. For me, I wanted to get the maximum value, so I opted to replace the three gang switch in my hallway. The hallway light switch operates the hall light, the porch light and the upstairs light. Three lights that are used pretty frequently.
I started by unscrewing the switch.
Then I stopped.
There were more wires than I expected!! I knew the upstairs light and the hallway light were three-way switched, but the porch light isn’t.
The back of the T1 looks like this:
I was going to need some professional help! Thankfully, as my father and two of my brothers are electricians, I could get *free* professional advice.
After getting a handle on the wiring, I realised that the T1 switches just wouldn’t work. No neutral connection was available. I mistakenly the blue wire to be neutral when it is switched live. I should have paid more attention when my father was teaching me this at age 15. I checked a few more of the switches and confirmed that there was no neutral in any of them.
The listing for the Sonoff switches on Amazon does indicate that a neutral is required, but since I mistook the blue switched-live for a neutral, I went ahead and bought them. I’ll be returning them.
This was a disappointment.
My main annoyance was that I’ve only had my house completely rewired last year. I was kicking myself because this should have been something I was aware of. That said, a lost of forum entries seem to indicate that most electricians won’t add a neutral that doesn’t connect to anything. Even if I did ask my electrician to add a neutral to each switch, he could very well have said no.
At this point, I took a step back. The Sonoff switches simply weren’t going to work.
The Lightwave RF stuff was too expensive for the purpose of playing around.
I needed a plan B. I decided to put one of the Sonoff Basic Smart Switch onto my porch light. This would mean leaving it switched on at the wall, but I figured that would be okay. I’ll do another post on that soon.
UPDATE 16 Feb, 2019 – Den Automation now offer smart light switches that work in the UK without the need for a neutral. I’ve written a post on the pre-ordered items I received.
As part of my ongoing experiments with C# and mDNS (to build my own Homekit accessory), I got to the point where I wanted to run my code on a Raspberry Pi.
Microsoft have released a version of Windows 10 that will run on a Raspberry Pi in a headless mode. The main advantage of this is that it contains the .Net Core runtime!
To get started, download Microsoft IoT manage and fire it up. Under the menu, you’ll see an option to Set up a new device. This lets you flash an SD card with the code necessary.
Once the formatting and flashing is complete, you’ll have an SD card containing Windows IoT. Pop this into your Raspberry PI, and after a minute or five it will appear under the My devices view.
To get me started, I launched Remote Powershell. When it started, I got prompted for credentials.
This includes the IP Address and the account Administrator (the password for which, you set earlier). I found that this just didn’t work. I replaced the IP address with the machine name (minwinpc) and it worked!
I just realised this is a real Windows XP dialog!
After Powershell started, I opened a file share and created a directory called Climenole. To get my little Console app ready, I needed to compile it for ARM. Thankfully, this was straightforward. From the command prompted, I ran this command
dotnet publish -r win-arm
This compiles the app for the win-arm architecture. From the project directory, you can access
to see all the published files. I took all these files and copied them across to the Climenol directory I created on the Raspberry Pi.
Once the copy completed, I could run my app using Powershell.
It didn’t work the first time as the hardcoded IP address wasn’t right, but after a tweak,
It started answering responses and even appeared in Homekit.
A good first step and proved that my mDNS was portable.
Next challenge is getting all the crypto code working, so that I can actually add and control the accessory from Homekit. It was a pain to get it working on the .Net Framework, so I suspect it will be no picnic on Core!
Update (07 Jan, 2019) I’ve had a couple of people ask to see the mDNS code. It’s up on Github – https://github.com/tomasmcguinness/dotnet-mdns
From Part 1 and Part 2, you can see we have grabbed the a request and parsed it successfully. The next step is to actually answer the request. At this point, I started using Wireshark. I didn’t use it in the beginning because I totally forgot about it 🙂
I found this interesting post – https://justanapplication.wordpress.com/category/dns/dns-resource-records/dns-txt-record/ – which seemed to describe the response format I was interested in.
It’s at this point that I realise endianness might be an issue! If you don’t know what endianness is, I envy you. Oh joy of joys. So after reversing all the arrays, my packet looked like a closer match and, success! A response!
Whilst this response doesn’t actually contain any information, it showed me that something was actually working. I then restored the code to include the one TXT answer. The packet appeared in Wireshark, but was malformed.
After more reading, I realised it was the way I was generating the name. I had just passed it in as a UTF8 Byte, but rather it should be broken out by the periods with length fields too. This explains a lot of the questions marks! More tinkering and BINGO! An empty TXT record response!
I was now feeling very confident and decided to see if my little Console App could actually respond to a genuine request. I downloaded a Chrome Store app called mDNS Browser (https://chrome.google.com/webstore/detail/mdns-browser/kipighjpklofchgbdgclfaoccdlghidp?utm_source=chrome-app-launcher-info-dialog). I had stopped using Bonjour Browser as I felt I kept needing to restart it. Running them both side by side….and nothing! I could see the mDNS request (after discovering you could filter Wireshark with mDNS!)
This was disappointing as I could see my console was sending a response, which I was knew was well formed. I played around a little, but still no joy. I did then notice that my app was answering its own queries!!
I made a small modification so that it only processed queries and not responses. This thankfully cut down the output. I’m not sure why I didn’t spot this before, but I assumed it was all the devices on my network advertising themselves. Running the request again:
Single request, single response. But nothing in Wireshark.
The app wasn’t generating any errors and I would receive and respond to multiple requests, so I was confident that the sockets themselves weren’t the problem.
One of things I had noticed when trying to get the receive to work, was that I had to enable the MulticastLoopback setting on the Socket. It then struck me that the reason I might not be seeing any response traffic in Wireshark was because the broadcast was going out on the loopback (this is 127.0.0.1 and prevents the network traffic going down too low in the networking stack) address!
Armed with this idea, I found an interesting post on StackOverflow (https://stackoverflow.com/questions/22504272/troubleshooting-udp-multicast-issue). I copied the snipped of code, tweaked it a little and reran my test. Amazingly, it worked!
Wireshark showed one _services.dns-sd request and one response with a TXT record. I checked the content and it matched up to my response!
Unfortunately, the mDNS Browser didn’t show anything.
There are two reasons I can think of; Either it’s not receiving the response or the response isn’t valid enough for it.
At this stage, It’s worth going back to brass tacks. I’ve got a good understanding of the DNS records and how they are structured, so I fired up my Homekit console app (which uses Apple’s Bonjour to generate the records) so get an example of what I need to be returning.
Wireshark yielded this:
So I have the broad stokes in place. I’m going to now try and just emulate this, using a simple A record to get me rolling.
Not a bad first attempt. The \004 and \005 artefacts were odd invisible characters from a copy paste, so I cleaned them up.
Next, I need to add an A type record. I thought this was straight foward, but in the process of comparing it to the sample Bonjour record, I noticed something odd.
The word local wasn’t actually spelled out. This implied it was a keyword or something. On inspection of the other records, in the Answers section, I found it to be the same. Reviewing the records in more details revealed there is some sort of pointer mechanism at work. I’m not 100% sure about this yet, but the PTR record seems to point to the TXT record
This, I’m guessing, is some soft of space saving approach. I’m just not 100% sure if it’s actually necessary. For the sake of keeping my code simple, I’m going to assume it’s optional 🙂
After much messing around, I still wasn’t seeing my responses in the Browser, so I decided to trim the packet down to the pointer. I also noticed that all of the other responses, included the original query, so I included that too.
Still no joy. I then discovered I was doing something stupid. Using the MDNS browser, I could see some responses from the devices on my network, but my own response never showed up. It was then I noticed the destination!
The other responses were directed at the source IP, where my own response was simply targeted at the multicast address!! In hindsight, it makes sense to respond directly to the person asking. I quick tweak of my code and bingo!
Encouraged by this, I restored all the other parts of the code to return the A records and PTR, SVR and TXT records too. Unfortunately, these didn’t appear in either MDNS browser nor the Bonjour Browser. For some reason, I decided to see if my iPhone Browser would work! Amazingly….
So my HAP entry appear. I drilled down….
And there is was! My TXT record and my IP addresses. I don’t know how it got the IP6 addresses, but I didn’t card. Feeling very optimistic, I updated the TXT record with the required Homekit TXT record fields and opened the Homekit app on my phone. Amazingly, my bridge appeared!!!!
Excellent. Next step is to deploy this little app onto my Raspberry Pi and see if it still works! I should point out that my implementation is woefully incomplete as regards the spec for mDNS, but the main aim was to have my accessory appear in Homekit.
In part 1, I wrote a simple Core console app that could log the multicast requests it received. Running the simple Bonjour Browser utility, I could see this being logged
The lines _services_dns-sd seems to indicate some sort of services request being made, which made sense, given that Bonjour’s purpose for existing is to advertise services on a network. A quick Google for _services_dns-sd lead me to this Apple article https://developer.apple.com/library/content/qa/qa1337/_index.html.
This confirmed my hunch.
Devices running mDNSResponder-58.6 (Mac OS X 10.3.4) or later will respond to the “Service Type Enumeration” meta-query described in Section 10 of the DNS-SD specification. Issuing a Multicast DNS PTR record query for the name “_services._dns-sd._udp.local.” will return a list of service types being advertised on the local network.
Aside from the full stops being displayed as question mark characters, this looked pretty sensible.
First order of business was to actually parse the byte into its parts and display them. Back to RFC 6762.
Section 18 talks about the message format, but deals a lot in bits, rather than bytes. To help me understand the values a bit better, I decided to write each request out as bits.
I got something like this (each byte in its own line)
00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00001001 01011111 01110011 01100101 01110010 01110110 01101001 01100011 01100101 01110011 00000111 01011111 01100100 01101110 01110011 00101101 01110011 01100100 00000100 01011111 01110101 01100100 01110000 00000101 01101100 01101111 01100011 01100001 01101100 00000000 00000000 00001100 00000000 00000001
I started by trying to compare each part to the corresponding bit outline in the RFC. Nothing matched, so I went back to Google and found this piece on Wikipedia (https://en.wikipedia.org/wiki/Multicast_DNS). A quick read and the first example looked like that I wanted.
00 00 Transaction ID
00 00 Flags
00 01 Number of questions
00 00 Number of answers
00 00 Number of authority resource records
00 00 Number of additional resource records
07 61 70 70 6c 65 74 76 “appletv”
05 6c 6f 63 61 6c “local”
00 01 Type (A record)
00 01 Class
To confirm, I went back to my C# and modified it to show the data in a similar shape.
Working with the first 12 bytes, I saw this in the console’s output
00 00 00 00 00 01 00 00 00 00 00 00
This looked identical to the example in Wikipedia. I then went about look for the null terminator. After some tricking around I ended up with this
00 00 Transaction ID 00 00 Flags 00 01 Number of questions 00 00 Number of answers 00 00 Number of authority resource records 00 00 Number of additional resource records 09 5F 73 65 72 76 69 63 65 73 07 5F 64 6E 73 2D 73 64 04 5F 75 64 70 05 6C 6F 63 61 6C _services_dns-sd_udplocal 00 Terminator 00 0C Type 00 01 Class
This is a near perfect match to the Wikipedia entry. The primary difference is the “Type” value (and the actual request content (_services_dns instead of appletv.local)
Type value of 0x0C is obviously different, so I hit Google again and found this lovely Microsoft article. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197470(v=ws.10)
It explains the various parts of the request/response and the 0C type is a PTR request. This seems appropriate for DNS service discovery! Huzzah.
Next step is to now respond with some data, probably in the form of a TXT record.