words from ppl.town

words.ppl.town

Recent posts

from tardisx

I bought a cheap IR blaster (the”Tuya WiFi IR Remote Control Hub WiFi Smart Home Infrared Universal Remote Controller For Alexa Google Home Air Conditioner TV”) for under $15AUD on aliexpress.

The first hurdle to overcome was to remove the default Tuya firmware (I never even installed their app) and install Tasmota on there. That's probably a subject for another blog, but the short version is:

  • I couldn't get tuya-convert to work, as I didn't have the right kind of wifi adapter
  • I soldered header pins onto the board (easy) and flashed it with Tasmotizer (which is just a front end to ESPtool) and a USB to serial TTL device.

So now it works, I configured MQTT and could successfully both capture IR codes and send them.

Cheap as the hardware is, it seems to be quite successful in sending IR signals, and has good coverage.

Now, to the actual problem, and the reason for this work. I'd like to be able to do more home automation of the TV, mostly to work around the awfulness of HDMI CEC. With multiple HDMI devices connected, the HDMI CEC should “just work” but in practice it doesn't. Some examples:

  • The Xbox One will switch TV on and off, but it doesn't switch to the correct HDMI input
  • Also, it issues a “power toggle” command, not discrete power on/power off commands, so if the TV is already on when you turn on the Xbox, it helpfully turns it off
  • The Nintendo Switch turns the TV on and changes to the right input, but bizarrely will not turn the TV off again when it goes to sleep

Ultimately then, I'd like to be able to independently of any other devices turn the TV to the correct on/off state and change to the correct input.

(I also got the IR blaster to be able to control my aircon, but that's the next project).

While I can learn any command I want via the Tasmota device, the problem is that the Hisense remote does not offer either discrete power buttons, or discrete input selection.

(The latter is particularly vexing, as the input selection is very awkward, with a slow popup menu in a grid format).

With some searching I did find a reference with codes in it, but they do not seem to be for my model, perhaps an older model?

The basics are easy enough, the remote sends using the “NEC” protocol, with a single 32-bit number for each command. For example, here is capturing the “volume up” button via MQTT:

topic: tele/tasmota_50930A/RESULT

payload:

{
  "Time":"2020-05-02T04:27:05",
  "IrReceived": {
    "Protocol":"NEC",
    "Bits":32,
    "Data":"0x00FDC23D"
  }
}

I thought it might be useful to see patterns in the groups (ie the relation between “channel up” and “channel down” in the old documentation vs how it works on my device), but it seems that these are not particularly consistent.

For example, pressing the digits 1-0 and capturing the codes results in (hex and binary):

  hex                   bin
00FD807F | 00000000111111011000000001111111
00FD40BF | 00000000111111010100000010111111
00FDC03F | 00000000111111011100000000111111
00FD20DF | 00000000111111010010000011011111
00FDA05F | 00000000111111011010000001011111
00FD609F | 00000000111111010110000010011111
00FDE01F | 00000000111111011110000000011111
00FD10EF | 00000000111111010001000011101111
00FD906F | 00000000111111011001000001101111
00FD00FF | 00000000111111010000000011111111

There's something like 12 bits changing around across there, so I have no idea how they related to the digits. I'm not much of an embedded person so there is probably a sensible reason that I can't see :–)

Now in theory, I can just run through ever code to find the ones I need. There are a few problems:

  • There's 2 billion possible codes
  • I have to watch the TV the entire time for feedback on whether or not each code did something
  • Some commands don't even have any affect depending on what current mode the TV is in (for instance, pressing the number keys while on a HDMI input)
  • I don't have 60-odd years spare to do that
  • I can't even be sure that discrete codes for the functions I want exist

Luckily there are a few ameliorating factors:

  • Every code I've learned has the same initial 16 bits, and this is the same in the old documentation
  • They are clumped into rough groups, even though it's not clear exactly what those groups are
  • There are discrete codes for the inputs and the power on/off in the old documentation, giving me some confidence they exist on my model as well
  • The discrete codes I want (inputs and power) should not be affected by the current TV mode

So, to search 16 bit of space is only 18 hours or so. Still annoyingly big, but manageable.

Obviously we need some automation to do this though, so I wrote a small script to help me:

#!/usr/bin/env perl
#
use strict;
use warnings;

use JSON;
use Net::MQTT::Simple qw/localhost/;

my $start = shift;
my $end   = shift;

$start = hex($start);
$end   = hex($end);

my $num = $end - $start;

printf("This will take %.2f minutes\n", $num/60);

foreach my $i (0..$num) {
  my $data = $start+$i;
  printf("Trying 0x%X - (remaining %.2fm)\n", $data, ($num-$i)/60);
  my $d = JSON::encode_json({ Protocol => "NEC", Bits => 32, Data => $data });
  publish("cmnd/tasmota_50930A/IRSend" => $d);
  sleep 1;
}

It takes two arguments, the start and end code (in hex). It'll run through the codes, one per second, zapping them out, and I get to sit there and see what happens.

$ ./test_ir.pl 0xFDE000  0xFDEFFF
This will take 68.25 minutes
Trying 0xFDE000 - (remaining 68.25m)
Trying 0xFDE001 - (remaining 68.23m)
Trying 0xFDE002 - (remaining 68.22m)
...

(Doing 0xFFF at a time is a reasonable “chunk” in terms of time).

I can verify it's working by having another window running mosqitto_sub or similar to watch the response topic:

cmnd/tasmota_50930A/IRSend {"Data":16637954,"Bits":32,"Protocol":"NEC"}
stat/tasmota_50930A/RESULT {"IRSend":"Done"}

(If I didn't see the “IRSend Done” I would know my MQTT messages were not being received and actioned by the Tasmota. This is important because you can't see Infrared beams to confirm it's actually doing anything, and most of these codes are going to have no other visible impact).

Once it's running, it's just a matter of sitting back and waiting. When something happens, I just press CTRL+C and re-run the script with a smaller range to narrow down the exact code and what it's doing, document it, and restart the script again.

One super strange oddity, once I discovered a couple of the undocumented codes I thought I'd search the web for them to see what I came up with.

So far, I got a single hit, on a Romanian web page, presumably selling the same remote as I have. The weird part is the hex code I searched for is on that page, but in white on white text so as to be hidden from view for humans. There was only a small handful of codes that I'd already discovered via learning them directly from my remote, so it wasn't useful as a reference.

At one point I found that the TV unexpectedly turned off (while playing a Switch game). I was initially jubilant, as I thought I'd discovered the power off signal. However I “rewound” a dozen or so codes and played them again – no luck. It seemed like I'd been wrong.

The next day I returned to it and looked further. I then looked at the MQTT subscriber and found that the Tasmota was no longer responding to IRSend commands. They were going into a vacuum! Looking more, I found the device was back on factory defaults (AP mode) and had lost all of its configuration.

This started a frustrating walk to reconfigure the device, where I found I had not documented the GPIO allocations for IRSend and IRRecv. I eventually found them again (and wrote them down this time). But while doing this I formulated a theory on what had happened.

My theory is that I had found the power off command. Unfortunately, the Tasmota device was connected to the Nintendo Switch's USB connector. When the TV turned off, the Switch detected that via HDMI CEC and also shut itself off. This would have corresponded to the time that the MQTT responses started not coming back. Unfortunately I believe the unexpected shutdown also killed the Tasmota configuration – possibly a combination of right after an IRSend where it updated it's NVRAM or similar caused it to corrupt and go back to factory settings.

Since this incident I have confirmed the found code for power off does work (and it is the discrete one, not the toggle), and now I've got the TV turned off and am walking through the range again looking for the power on command.

Here's the codes I've found so far, either from learning from my remote or via brute force. As you can see, some of the functions are not entirely clear to me :–)

Finding the discrete power on and power off was crucial, but I have so far not had any luck finding any of the HDMI inputs – I hope they exist.

hex        function
-----------------------------
0xFDFA05 | apps
0xFD12ED | back
0xFDAA55 | blue
0xFD52AD | channel +
0xFDD22D | channel -
0xFD9A65 | channel list
0xFD00FF | digit 0
0xFD807F | digit 1
0xFD40BF | digit 2
0xFDC03F | digit 3
0xFD20DF | digit 4
0xFDA05F | digit 5
0xFD609F | digit 6
0xFDE01F | digit 7
0xFD10EF | digit 8
0xFD906F | digit 9
0xFDE817 | direction down
0xFD18E7 | direction left
0xFD9867 | direction right
0xFD6897 | direction up
0xFDB847 | epg
0xFD3AC5 | exit
0xFDCA35 | green
0xFD04FB | home
0xFD30CF | info
0xFD48B7 | input
0xFDD827 | live tv
0xFDB24D | media?
0xFDCC33 | media?
0xFDBA45 | media?
0xFD708F | mute
0xFDE21D | Netflix
0xFDA857 | ok/enter
0xFD847B | ok/enter?
0xFD956A | pause
0xFD08F7 | picture mode
0xFD15EA | play
0xFD8B74 | power off
0xFD0BF4 | power on
0xFDB04F | power toggle
0xFD4AB5 | red
0xFD1AE5 | rewind
0xFD28D7 | settings (cog)
0xFD8877 | sound mode
0xFD11EE | spinning blue circle then nothing
0xFD5AA5 | stop
0xFDF807 | subtitles
0xFDA25D | teletext?
0xFD8A75 | time shift
0xFDC23D | volume down
0xFD22DD | volume up
0xFD2AD5 | yellow
0xFD55AA | YouTube
 
Read more...

from tardisx

First off, let me say that I'm not actually convinced that there is any future for social networks. I don't mean that they won't be successful, or popular, I mean that there seems to be a inevitable slide towards “evil” on any large social network.

I'm not sure that humans are capable of having large conversations on a large scale. We've evolved the ability (through technology) to broadcast our individual voices to a larger audience than ever before, and we are demonstrably not ready for it.

Is more technology the answer? It's the only potential path that I can see, this is a genie that very certainly cannot be put back in its bottle.

So let's put on our +1 glasses of optimism and look at what's out there.

Mastodon

I will admit to never being a fan of twitter. As someone who saw it from its inception as a 30-something, I never saw the appeal of telling my followers what I had for breakfast in 120 characters or less. As it grew into a mainstream platform for communication I found it difficult to reconcile the faintly ridiculous origins, the obnoxious celebrities and the technical limitations with it being a serious platform (for me). The numerous examples of the platform being a toxic place for almost any minority group and the misuse of it as a political weapon are simply additional nails for that particular coffin.

Mastodon fixes at least some of these concerns. It provides a safe space for minority groups. I've have learned so much about the daily struggles of a bunch of groups that I doubt I ever would have otherwise, and I certainly would not have encountered these people at all on twitter. It's been a large leap out of my comfort zone in a lot of ways, and that's a good thing.

What's wrong with Mastodon? The age-old problem of the “new platform” – getting users. Even though Mastodon take-up has been enormously successful compared to most other “new” platforms, you could still ask any nearly anybody about it and get the response “masta-what??”.

Relatedly, the “finding people” thing is still difficult. I run my own instance (because that's point of decentralisation, right?) but that does make it difficult to find new users and content.

Scuttlebutt

While it's been around for a while, I only discovered Scuttlebutt fairly recently.

Technically, I like some of the concepts a lot. The LAN discovery concept is neat, and the way that your social network feed works and grows is interesting.

Unfortunately there are some significant downsides, the biggest one being that every device is basically a new entity. People want to be able to “be” the same person on their mobile device and their computer, and the inability of the platform to properly support that (at the moment) is a major issue.

Additionally, the defacto software is pretty clunky, and it suffers from the same confusion that I'm sure turns off many new users. Having to tell someone that “the network is called Scuttlebutt but the software you use is called Patchwork... though actually, the protocol it uses is called SSB which stands for Secure Scuttlebutt” is a pretty poor user experience.

Mastodon isn't particular different in this regard, but at least people need nothing more than a web browser to get started – a much lower barrier to entry.

What else?

I've only touched on “public” social networks here, and but briefly.

I've also looked extensively at more “private” messaging platforms, as a response to the increasingly invasive amounts of data collection among all of the popular messaging platforms.

But that's a topic for another post.

#socialnetworks #future #patchwork #ssb #scuttlebutt #mastodon

 
Read more...