words from ppl.town

words.ppl.town

Recent posts

from tardisx

I've been a perl programmer ... forever. It's literally been my entire career. I'm thankful for its existence. Very much so. It's enabled me to do great things, both personally and professionally.

It's not cool and shiny any more. Actually, not true. It's not shiny, but it's still cool. There are still many, many amazing things being done with perl on a daily basis.

When I look around at the syntax of other languages and the frameworks, I often find myself surprised at how primitive they are, or how hard it is to make perform simple operations. Or how hard it is to perform complex operations – spin up a RESTful web server, pull rows from a database, talk to an API. All the stuff that perl has made incredibly easy.

It's been a good run.

No, it's been a great run.

And the run isn't over. I'm still going to reach for perl all the time – because there is simply no better tool (in my opinion) for solving an awful lot of problems. I've been using it a long time, and I know I can get things done with it very easily.

But, I need to eat, I need to pay bills.

And I want to do a few of the things that perl just isn't very good at.

The “paying the bills” part has not been a problem thus far. But if I was needing to look for work right now, it might be a challenge. “perl” as a keyword comes up an awful lot in job ads, but almost always (these days) it's one of a long list of “also familiar with” items.

I'm not a one trick pony, I haven't lived and breathed nothing but perl for the last 25 years. But I have a healthy case of imposter syndrome, and I know what I'd be able to confidently say I'm good at, and what I would struggle to defend as a core skill.

Additionally, I can't (in good conscience) go into an employer who offers me a green fields project and use perl. I could 5-10 years ago, but not now. I'm only one person and if I'm not around I don't want to leave that employer struggling to find someone to maintain and improve that project. That doesn't seem fair.

But even if there's money in it, I don't want to be like the Cobol programmers. Those poor bastards.

So – to move onto the technical aspects of moving on. What is perl bad at?

(And to be clear, I don't consider these necessarily “general” deficiencies, just problems that I would like to solve for my own reasons).

multiprocessing

We all know that threads are evil of course. And that there are plenty of ways to do multiprocessing on perl without them, (like this and this or even this.

None of them are baked into the language.

easy deployment

I like writing software for me but I really like writing software for others. Stuff that's useful, general purpose. I like to solve problems for non-technical people, or at least, people who are less technical than me. Or, lets cut to the chase, people for whom instructions that begin with “step one, install perl” are not going to fly.

Even if I'm writing something for the web, deployment is still not as easy as it might be. I've accrued a pretty big bag of tricks over the years of doing this, but none of them beat just throwing at executable file at a person, or at a server.

(BTW – I was heavily disappointed to find that Raku did not prioritise improving on this particular pain point. Maybe I'm the only one with this problem :–)

modern tooling

This one is a bit of a catch-22. I don't need the fancy tooling on perl because I pretty much know it inside out. An IDE would be useless. I know where the documentation is. I don't need to be able to look up method calls in a context menu.

But ... these things are nice. It's nice to use a language that can look up method calls inside an editor because the syntax is well defined and the language is introspectible and it can't create create named methods at run time.

I know that last thing is cool and amazing and I've done great and terrible things with it but .... I think I'm over the fancy tricks. People are always going to scream when there is only one way to do things, including me, but even if you have to work harder now, future-you looking at that code is hopefully going to be less surprised.

If you don't know what I am talking about, this may help.

Back to tooling – those limitations in a language at least mean that the ecosystem of the infrastructure around the language has a much better chance – especially the tools that assist with the nuts and bolts of the actual coding process.

So...

Well, I did kind of give away the punchline with the title.

I've been playing around with Golang for years (and Python and Java and Swift and Rust and C) but I think I have finally gotten over the initial “hump” that moves one from “yeah, I know what that is and the basic syntax” into “yeah I know what that is and the basic syntax and I'm almost starting to understand some of the idioms and patterns”.

(Learning a new programming language is “surface level” trivial, “substance level” decades of work)

That hump is arbitrary and so is my declaration that I've passed it. I've written a couple of toy things, and one not quite toy thing. I'm no expert. I haven't even got my training wheels off yet. But now I'm at least at the point where when starting a new (small) project I can stomach the idea that doing it in perl would be easy, but doing it in golang would be rewarding and a good learning experience (and a lot of hard work).

But it's fun. And I hope it will also open some new doors.

 
Read more...

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

Update October 2020

A kind reader (thank you D. Smith) has informed me of how the NEC protocol works, and how the address space is effectively only 8-bit.

Unfortunately this means that I have searched without finding codes for the HDMI inputs 😆

I do have a workaround, which is to use the “input” code, the “direction” codes and “enter” to choose the input. The inputs are re-ordered based on the current input (sigh) but I can workaround that by first switching to “Live TV”, which will then present the inputs in a fixed order.

 
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...