The past few months have been quite hectic and I have nearly rewritten the whole codebase, but I feel like the software is now at a stage where it’s mature and stable enough to be used by a larger audience.
The changelog is quite big, but it doesn’t even cover all the changes, as many integrations have been completely rewritten.
The biggest (breaking) change is the merge between plugins and backends. Now, except for those integrations that actually listen for messages and execute them (like HTTP and Redis), all the other integrations are plugins. This greatly simplifies the configuration and removes a lot of confusion for new users.
The Docker support has been greatly improved too. There are now officially supported multi-arch images for Alpine, Debian, Ubuntu and Fedora, an official docker-compose.yml file, and both the platydock and platyvenv utilities have been almost completely rewritten to seamlessly automate the creation and configuration of containers and virtual environments (respectively) starting from a single config.yaml.
And the Python API has become much simpler and consistent. No more __init__.py files that the user had to manually create in each subfolder of scripts, just drop a .py file with your automation in the scripts dir and it’ll be picked up. Moreover, the most common imports are now available on top level as well, and there’s no more need to create procedures/hooks/crons with varargs:
from platypush import run, when
from platypush.events.sun import SunsetEvent
@when(SunsetEvent)
def sunset_lights_on():
run('light.hue.on')
There’s also a revamped documentation portal, which now includes both the wiki and the plugin reference.
Most of the integrations have been rewritten at different degrees, and in the process many bugs have been squashed, many features added and many APIs updated to be more consistent, so make sure to check the documentation pages of your integrations in order to migrate.
Is anyone aware of ways to control #ffplay programmatically in any form, without having to focus the window and having to emulate keyboard/mouse bindings in it?
ffplay is amazing, light, fast, and it’s a player that comes with any #ffmpeg installation.
#Platypush supports media players such as VLC, mpv, mplayer, omxplayer and gstreamer, but they all come with their bags of issues - the VLC libraries seem to break too often on Wayland, mpv has too many API breaking changes across versions and controlling it only works if the version of the library and the player are carefully aligned, mplayer is an unmaintained dumpster fire with a messy control API, working with gstreamer in Python requires the user to install the whole fat GLib luggage and MBs of plugins, and omxplayer is basically dead.
ffplay would be my favourite pick for a portable and lightweight default media player. But the fact that it apparently can’t be controlled in non-interactive ways really puzzles me.
@cory the idea sounds similar to what I’ve done a while ago with #Platypush + #mopidy (and optionally Tidal). My implementation also uses the scrobbled tracks over a certain period and Last.fm’s API to automatically generate a “discover weekly” playlist.
I haven’t toyed with Plex in a while, but why did you have to run everything on Firebase/Supabase? If you have your Plex server running locally isn’t it more convenient to go for a fully local solution?
I’m impressed to see that my #Neovim extension to send HTTP requests directly from the editor (it basically emulates the logic of IDEs like VSCode and IntelliJ with .http files) has already reached 65 stars! ⭐️
There already a couple of feature requests that I’d like to tackle (I don’t open Github that often, so I missed the past 2-3 months of notifications), but I’m really struggling with time.
#Platypush takes most of my time, as I’m trying to wrap everything for the first stable release (it only took about 8 years!). The Platypush web extension, the Platypush Android app, the madblog blogging platform and the RSS viewer browser extension take my remaining (unpaid) development time. And there’s still sporadic work I’m doing on Mopidy, Jellyfin, OpenLineage and other projects.
I released nvim-http as a toy one-shot personal project, covering what I perceived as a gap in the Neovim plugins and hoping that I wouldn’t have to come back to it again. But, 65 stars and 10 open issues later, it seems like others liked the idea too - and it’s probably fair to implement the improvements that they’re asking.
Is there anybody out there who’s familiar enough with #Python (or if you want to rewrite in #Lua, feel free to do it too, as I’ve been toying with the idea a bit already) and uses Neovim who would like to give me a hand with this project? I’m happy to add new maintainers/contributors if they can prove enough proficiency with Python and/or writing Vim/Neovim plugins. Otherwise I may eventually respond to all the open feature requests, but squeezing in another project to maintain regularly may prove tricky for me.
I wish that #Python developers didn’t write their libraries with asyncio.get_event_loop() and loop.add_signal_handler everywhere like it’s JavaScript.
I know that managing the lifecycle of your own loops can be a hassle in Python (and I wish that the asyncio API did a better job at it), but writing Python libraries in the async JS flavour is basically a guarantee of being thread-unsafe and thread-incompatible.
add_signal_handler uses the set_wakeup_fd C API under the hood, which only works if the file descriptors are initialized in the interpreter’s main thread.
I’m now working on rewriting the #Telegram integration in #Platypush (it’s been broken since the Telegram bot API migrated to the new asyncio paradigm). Since the new code uses get_event_loop and add_signal_handler everywhere, I have to come up with a complex architecture that involves at least a separate process for the Telegram listener (with its own event loop which uses the bot API), another thread as a bridge to run commands on the loop using run_coroutine_threadsafe, and at least two inter-process queues to send commands and receive responses with the integration thread which runs on the main application process.
To all the Python library developers out there: I know that it’s tempting to use the asyncio API like it’s JavaScript, and forget that your code may run in multi-threaded contexts. But please, try and go the extra step and manage the lifecycle of your own loops. Prefer new_event_loop+set_event_loop over a bare get_event_loop. Avoid add_signal_handler if possible, instead opt for asyncio.Event with an option to specify a compatible event class instance (like threading.Event or multiprocess.Event), so we can easily adapt your library’s synchronization mechanisms to our projects’ concurrency models rather than the other way around.
Many users of your libraries who want to run them in a separate thread will very very grateful for helping you keep their code simpler.
We may still have to use the *_coroutine_threadsafe APIs as a proxy, but at least we won’t have to come up with multi-process architectures and communication protocols to accommodate your library’s constraints.
I guess it's again #introduction time, as I've just moved over from @blacklight. So there we go:
🇮🇹 geek in his mid-thirties, based in 🇳🇱
👔 My job involves solving problem at scale, one line of code at the time, with varying degrees of success.
⚙️ My hobbies often involve automating everything around me.
:linux: #Linux user since 2001. Like many in my age group, I also used to run a forum and a wiki on an old Pentium 1 repurposed as a Slackware-based server under my bed.
:arch: #Arch Linux and rolling release enthusiast.
🛠 Creator and main developer of #Platypush (https://platypush.tech), an open-source, general-purpose platform/framework to automate everything. With hundreds of available integrations, you can think of it as IFTTT+Tasker+SmartThings on steroids, scriptable, and runnable on almost any device. Or maybe like HomeAssistant's more hackish brother.
A big change for #Platypush - and more are on their way before the next (very big) release.
The #YouTube integration has been completely rewritten to remove all the references to the YouTube API. I've tried my best to play fair, but the YouTube API has seen way too many breaking changes recently, as a result of Google's strategy against scrapers and 3rd-party clients. I just can't keep maintaining an integration with an API provided by a company with such a hostile stance against developers.
I want to spend my time making new things work, not fixing stuff purposefully broken by someone else. Even just searching for videos now requires a registered and approved Google project, and the user to be logged in: this isn't exactly the kind of stuff that is easy for anybody to set up and run.
Also, scraping results from the Web interface is no longer possible unless the user has JS enabled - which means no more easy beautifulsoup scripts, one has to summon Selenium and its whole frontend suite to scrape stuff.
From now on, the YouTube integration will use #Piped as a backend instead. A simple public API, subscribe to search results and feeds through simple RSS syndacation, and no more headaches with Google. This is what the developer experience with YouTube used to be until a few years ago, and how it should have remained.
There we go - the technological #enshittification pandemic has also reached Philips #Hue.
Apparently they weren't making enough money by selling bulbs at $50/70 each. They'll now force you to log in through their app to the bridge too, or all of your bulbs will just stop working.
What this means, among the other things, is that tons of unofficial integrations that have been built over the years (phue being one of them, which I contributed to in the past, and is also used by Platypush to interact with Hue bridges) are also likely to stop working once you upgrade your bridge's firmware. Those integrations leverage the old push-the-pairing-button mechanism to pair with the client, but now in-app authentication through a registered account seems to be a requirement - and I definitely have better things to do with my time than reverse engineer again their shitty authentication flow and push a PR to phue.
Philips Hue (sorry, Signify B.V.; Philips has actually given up on building anything, they're just waiting for everybody who works there to retire) has joined the long wagon of companies that have realized that scooping up as much data as they can from their users (that probably includes at what time you usually wake up and go to sleep, from your bedroom lights patterns, or how often you go to the toilet) and selling it to data brokers provides a much steadier revenue stream than selling actual products that people want (even if those products are already quite pricey). And they don't care if fullfilling their new missions of being a mere data collector rather than a tech company means to literally break overnight the lights in the houses of millions of customers.
Of course, I was kind of prepared for this. I have #Platypush installed on a RPi with a Zigbee dongle and zigbee2mqtt, and it already does the job for a bunch of Hue, Ikea and other cheap Zigbee lights. That's all you need to make your own Zigbee bridge. #HomeAssistant and #OpenHAB are other popular options.
But it'll still take me a while to unpair a few tens of Hue devices in my house that are still connected to my Hue bridge (which I purchased a decade ago btw), and reconfigure tens of groups, scenes and automation routines on my self-managed bridge instead.
I used to love being a software engineer, building things and solving problems. Now being an engineer sucks, even as a hobby, and I don't feel anymore like this is what I want to do with my life.
It's not up to me to decide what to build anymore. It's up to Spotify killing their streaming libraries, Twitter or Reddit killing their API, Hue breaking their products if you don't log in through their app, YouTube coming up with ways to break youtube-dl on a daily basis, Google breaking your browser extensions, Red Hat and Docker turning suddenly hostile towards the FOSS community that made their fortunes, Messenger periodically logging out your alternative clients and locking your account, an increasing number of companies who insult the large community of unpaid volunteers that builds against their ecosystems as "free-riders" and make it their business mission to break their implementations, and the list could go on forever.
I'm no longer working with ecosystems built by companies who genuinely want to build good things that people want to use, who treat the community of developers around them as an asset rather than a liability, and even sport "don't be evil" among their core values. I'm working in an industry that continuously takes hostile stances against the FOSS community, unofficial clients, and anything that doesn't fit neatly into the quarterly vision for profitability outlined in the PowerPoint deck of a sociopath product manager with no tech background, and who couldn't care less if they are selling IoT devices or bricks. And I have to dodge these attacks on a daily basis, one line of code at the time, for the hundreds of integrations available in the projects I maintain or contribute to, just to keep things working without losing features overnight.
I wake up the morning thinking "how will tech companies decide to fuck me up today just to get one more byte about me to sell to data brokers, and which activities will I be forced to put aside in order to write some code that fixes the UX-breaking shitshow that one of their greedy managers has decided to put up today in an effort to beef up their quarterly bonus with a +1% uptick in revenue?"
Congratulations, motherfuckers. Your broken business models have broken tech for everyone.
It's good that other people are also bringing up the elephant in the room: why do you need to pay money for one more electronic gadget that listens to you 24/7, when voice assistants aren't supposed to be rocket science in 2023 anymore? https://news.ycombinator.com/item?id=35857631
Compared to 3-4 years ago, I think we're now in a state where the content is no longer the issue (just plug into a LLM, and all of your text requests will get an answer), nor integrations are a problem (just write a Platypush event hook on speech detected, and you can connect it to everything, no need for "Works with Google/Alexa" labels). Text-to-speech synthesis has also become cheap and ubiquitous.
But the hotword detection and speech-to-text models are still IMHO the bottleneck. Hotword detection is a field where you need a very small and lightweight model that only detects a specific word or phrase in a very reliable way. Snowboy was an amazing FOSS project - which also came with this cool idea of "crowd-funded models", where in order to download a model for a certain hotword you were first supposed to provide three audio tracks where you say that word in order to improve the model. But it's now discontinued because it cost the volunteers too much to run the infra.
And Mozilla DeepSpeech is a relatively good choice for general-purpose speech-to-text, but it's heavy (it takes 100% of the CPU when it runs on a Raspberry Pi) and it's mostly optimized for English - even support for other Western languages is patchy. OpenAI's recent Whisper model seems like a solid alternative, but it's also plagued by the 100% CPU issue - also, I no longer trust anything that comes from OpenAI, no matter how noble some of their efforts may look.
If there are other open-source alternatives that solve these problems, I'd be very happy to learn about them. Once these blockers are removed, there should be really no reason for anyone to feed their audio streams to Google or Amazon.
In the meantime, I'm planning to spend some time playing with some self-hosted LLM model to see if I can replace the Google Assistant library on the last Raspberry Pi that runs it in my home.
I have improved the loading performance of the new #Platypush entity dashboard by 200% with a simple fix.
Using a font-awesome CSS class instead of an animated GIF for your loading spinner can make a huge difference, if that loading spinner is supposed to be used by 1000 components on a page.
My current job is about fixing and automating global supply chains, one line of code at the time, but I have worked in a wide range of industries over the past (nearly) two decades.
My hobbies often involve automating everything around me.
:linux: #Linux user since 2001. My experience as a Linux admin started back in a time when I used run my IRC and Apache servers on a repurposed Pentium 1 under my bed, and it still took about 10 💾 to install a full Slackware system.
:arch: #Arch Linux and rolling release enthusiast.
🛠 Creator and main developer of #Platypush (https://platypush.tech), an open-source (mainly :python: and :vue:), general-purpose platform/framework to automate everything - from smart devices, to cloud services, to robots, to DevOps operations, to everything in between. With hundreds of available integrations, you can think of it as IFTTT+Tasker+SmartThings on steroids, scriptable, and runnable on almost any device. Or maybe like HomeAssistant's lighter brother.
Admin of https://social.platypush.tech, a Mastodon instance where I may talk a lot about Platypush, automation, programming, electronics and maths. I tend to write a lot, so if you're looking for an instance with a 10,000 characters per toot limit...
Looking for relays with instances dedicated to similar topics. My dream would be to build an experience, when it comes to #Fediverse#relays, that is akin to curated #OPML lists, where admins can create curated federated experiences for the users on their platforms, rather than the open-to-everything overwhelming stream of toots on the federated timeline that most of the relays provide nowadays.
I may often write about random politics/economics/philosophy. I may sometimes be very passionate on topics such as open-source, open data, open protocols, tolerance and social inequalities. I mostly belong to the progressive/social-democratic field. You are welcome to try and change my mind, as long as you do it in a civilized and data-driven way.
🏄 and 🛹️ rider. And, as a good Dutch resident, 🚲 enthusiast.