In the next paragraphs I will show you how did I build my first TV led strip. I will show you the parts that I’ve used, how to install the software, and also the way I’ve assembled everything in a small box on the back of my TV.

The first thing that I did was to buy an ESP8266. I bought this one from Mauser.

I’ve connected the ESP8266 to my PC with the USB cable. And uploaded to the device. How did I do that?

The WLED binary that I’ve used was WLED_0.10.2_ESP8266.bin that I’ve downloaded from the releases page.

I use this great tool esphome-flasher. Downloaded the latest release here. Just run the tool and choose the previous downloaded binary. Don’t forget to have the device connected to the USB port of your computer.

In my computer the device shows up in COM4 port.

After that your newly flashed WLED device should give you an access point named WLED-AP. Connect to it with wled1234 password. I connected with my phone and I was immediately redirected to the first time configuration web page. If this doesn’t happen to you, open the browser and go to 4.3.2.1 you should see this page.

Insert your home wifi SSID and password, click Save & Connect.

Your device will reboot and connect to your wifi network.

Find the IP address of your device using one of the thousands of network tools available on the internet and open your browser with that IP address.

And that’s it. You have your WLED device installed and ready to use.

For the LED strip I bought from AliExpress. It’s a 5 meter WS2810 LED strip (individually addressable leds). The next configuration is the LED count. For that, I needed to measure my TV, cut the strip and count the number of LEDs that I was going to control. For my TV I have 18 leds on each side and 32 leds, top and bottom. That gives me a total led count of 100.

Now for the wire connection, this is how you should do it. Im using a 5V led strip so I followed the first option in the schematics picture below.

I took this picture from projectwiki – https://github.com/Aircoookie/WLED/wiki

If the distance between the device and the led strip is long you should use a level shifter. That was not my case so I didnt have the need to include one in my solution. I used the 470 ohm resistor and and the 1000 uF capacitor.

Because I used the nodemcu, it is an ESP8266 device, I connected the D4 pin to the data input on the led strip. The led strip has3 conductors, 5V, GND and DATA.

I connected the 5V and GND not only in the beginning of the led strip but also in the end. The data input, that is connected to D4 pin, it is only connected in the beginning of the strip, and there is an arrow on the strip pointing to the data signal flow direction.

And that’s it! I can know control my TV led strip thru the web interface and I can also use the WLED mobile that I’ve installed on my smartphone.

Enjoy!

The post WLED – Check how I built my first TV led strip super easy appeared first on Blog IT.

I use the Home Assistant add-on named mosquitto as MQTT for everything so I can keep the communication system the same for all my devices and keep the management system simple.

First of all I configured my Shelly 2.5 thru the web interface to use MQTT. This is done in the “Internet & Security” configuration settings, “Advance Developer – Settings”.

I configured the username and password that was set in Mosquitto MQTT server in Home Assistant. Don’t forget the IP address of the Home Assistant server (port 1883).

I’ve used a custom MQTT prefix as you can see in the yaml files configuration below. I use this prefix as a way to give a name to my switch

# lights
light:
  - platform: mqtt
    unique_id: luz_sala_jantar_tecto
    name: "Luz do tecto da sala de jantar"
    state_topic: "shellies/sala_tecto/relay/0"
    command_topic: "shellies/sala_tecto/relay/0/command"
    payload_on: 'on'
    payload_off: 'off'
    retain: false
    qos: 1
  - platform: mqtt
    unique_id: luz_sala_estar_tecto
    name: "Luz do tecto da sala de estar"
    state_topic: "shellies/sala_tecto/relay/1"
    command_topic: "shellies/sala_tecto/relay/1/command"
    payload_on: 'on'
    payload_off: 'off'
    retain: false
    qos: 1

The Shelly 2.5 has temperature sensor so I’ve configured it like this

sensor:
  - platform: mqtt
    unique_id: sensor_temperatura_sala_tecto
    name: "Temperatura da luz do tecto da sala"
    state_topic: "shellies/sala_tecto/temperature"
    unit_of_measurement: 'ºC'

There is a power sensor so check the configuration here

sensor:
  - platform: mqtt
    unique_id: sensor_potencia_sala_jantar_tecto
    name: "Potência da luz do tecto da sala de jantar"
    state_topic: "shellies/sala_tecto/relay/0/power"
    unit_of_measurement: 'W'

And for the energy sensor, this is the way I’ve set it up.

sensor
  - platform: mqtt
    unique_id: sensor_energia_sala_jantar_tecto
    name: "Energia da luz do tecto da sala de jantar"
    state_topic: "shellies/sala_tecto/relay/0/energy"
    unit_of_measurement: 'Wh'

And I’ve used a binary sensor for the the temperature alert.

binary_sensor:
  - platform: mqtt
    unique_id: alerta_temperatura_luz_sala_tecto
    name: "Alerta de temperatura da luz do tecto da sala"
    state_topic: "shellies/sala_tecto/overtemperature"
    device_class: "heat"
    payload_off: "0"
    payload_on: "1"

If you want you can check the Shelly 2.5 specification here at the official Selly website.

And I’m a Mauser.pt store fan so go check the site.

The post Home Assistant with Shelly 2.5 switch the easy way appeared first on Blog IT.

Using an approach and code that initially was similar for example to Jan Tielens’ in his “Raspberry Pi + GPIOs with DS18B20 + Azure + C# = Internet Thermometer” article, and which I’ll describe in a later post, I now have my Pi2 sending temperature readings to an Azure Event Hub using REST, from where it is read by Azure Stream Analytics and then dropped into an Azure SQL Database. I still hope to wire this up to PowerBI, but there doesn’t seem to be a way at the moment to connect my MSDN Azure account with my corporate account where we have 100 PowerBI licenses, so that will have to wait.

What I wanted to share for now are some tips regarding the process, which are not described elsewhere in other articles I read on the net, and which I guess are very specific to the IoT/sensor world (to which I am new). Keep in mind that my simple goal was to have the Pi2 send temperature readings to Azure every minute.

Service Bus Queue vs Event Hub

My initial code was posting readings to an SB Queue. I didn’t antecipate using Event Hubs, since an event every minute doesn’t justify the platforms’ capabilities. Turns out that Azure Stream Analytics doesn’t support SB Queues as the source, so I had to change the connection code that posts temperature readings using REST. The changes were very few, but included:

• Dropping the support for custom headers, which I was injecting in the message sent to the Service Bus (example: sensor id). I had to move this information into the message payload itself;
• Changing the URL to which the message is posted, including the API version. To write to SB I was using https://myservice.servicebus.windows.net/queuename/messages?timeout=60&api-version=2015-01 and had to change this to: https://myservice.servicebus.windows.net/eventhubname/messages?timeout=60&api-version=2014-05 .

Reading the Temperature – closing the Stream

The code that reads from the sensor, in Jan Tielens’ code (and other similar code found on the net), doesn’t allow for repeat readings in a loop. This line of code:

var w1slavetext = deviceDir.GetFiles(“w1_slave”).FirstOrDefault().OpenText().ReadToEnd();

… actually leaves a text stream open (StreamReader class), that has to be closed for repeat readings to work. So that was another fix.

The main loop – time between readings

My application is simple console application implementing a while(true) loop, that does this:

• Read a temperature value from the sensor
• Send a message to an Event Hub, by doing an HTTP post of a JSON-serialized message
• Wait for 60 seconds with Thread.Sleep

One thing I noticed was that the readings were spaced, not 60 seconds, but 60+something. This “something”, usually 2-3 seconds, were obviously caused by the time the first two steps took. So to fix this I created a System.Diagnostics.Stopwatch at the start of the main loop, and at its end waited for 60 seconds minus the time it took for the first 2 operations to execute.

Now the readings were close enough (to a few milliseconds) to one every minute. Simple fix, simple mistake to make.

The main loop – long operations

The previous solution has a problem, which I quickly found out about. After running for a few hours, I had some posts to the Event Hubs that took a long time. More than 60 seconds. Maybe the cause was some Wifi problem, or network issue, don’t know. But what this meant was that I was calling Thread.Sleep with a negative value, which crashed the app. So another fix: if the operations took more than 60 seconds, don’t sleep and do another temperature reading immediately.

The main loop – SHA tokens’ lifetime

At the top of the app, before the main loop, the first thing I do is to create a SHA token used to connect to the event hub. This token has a lifetime, which I think is one hour by default. So, as you can expect: after one hour of reading temperature (60 readings), the SHA token expired, and sending the message failed with a 401 (permission denied), and I had an exception that stopped the app. Back to the code, another simple fix: wrap the sending of the message to the eventhub (which uses the WebClient class) with a try/catch, and when I find a WebException with 401 as the error code, recreate the SHA token and send the message again.

The main loop – the all encompassing try-catch

The last fix I did after I started having unhandled exceptions which I am not sure are due to the Pi2, Mono, network, whatever: I just wrapped the code inside the main loop inside a general try-catch, logged any error to the console output, and continue the loop execution. A “just in case” solution.

Finally, getting information about the device

This is not specific to the handing of the readings themselves, but I think is relevant. In the payload of my messages I wanted to include some information specific to the device, and found out I could find this information by reading from some devices/streams provided by the Raspian OS. I dug into some samples in the net, and ended up doing code that gets both the serial and the model name. The OS calls I do, using the Process/ProcessStartInfo classes as a way to get into bash are:

cat /proc/cpuinfo | grep Serial | awk ‘{print $3}’   — this gets you the device’s serial, for example “00000000f5b55a06”

cat /proc/cpuinfo | grep ‘model name’ | head -n 1 – this gets you a string from where you can extract the model name, for example “ARMv7 Processor rev 5 (v7l)”

I’m still cleaning up the code and making sure it’s stable, but I’ll post it to github pretty soon. Contact me if want to see it sooner. Anyway, what I did already realize is that the colder time of the day, in my place at least, is between 22:00 and 02:00, which surprised me, and the temperature variation is about 4 Celcius on average.  Interesting info!

The post IoT: Raspberry Pi2 and Azure Event Hubs and Mono and SQL Database–experiences appeared first on Blog IT.