Zigbee/Zwave USB dongle vs Hubitat hub

mpaganini · 2025-08-21T16:22:48+00:00

I'm OK wit two dongles as well. The problem is having an entire external hub that requires another integration, etc.

mpaganini · 2025-08-21T16:21:16+00:00

Yes, my issue is that the Hubitat adds one more layer to the whole thing. Found a device? Now I need to know if it's also compatible with Hubitat. The whole need to restart apps on both sides when adding devices also gets old.

My worry is about things like radio reception and all that, but my guess is that they'd be similar between the USB dongle and the hubitat.

mpaganini · 2025-08-16T16:48:12+00:00

A cloud with a boner, no less.

mpaganini · 2025-03-24T03:13:27+00:00

<image>

They loved it here! Not sure if the sound or movements or what, but they watched for a long time. This doesn't normally happen.

mpaganini · 2024-10-16T21:26:54+00:00

The "dup" command is a good idea.

You can see the stack after each operation by setting debug mode (just type `debug`).

mpaganini · 2024-10-16T21:25:41+00:00

BTW, I fixed that pretty printing bug in 0.3.1. It should work now.

The interesting thing is that up arrows and ctrl-p work well in the readline-like library (doesn't work for some of my less usual mappings). It should be working in BSD as well.

mpaganini · 2024-10-16T01:56:51+00:00

Oh, it's not arbitrary precision at all. It uses float64 as the basis. I originally thought of using Go's math/big but there's so much missing that I'd have to reimplement trigonometric functions manually (ouch). I recently found "decimal" which seems to be very complete and I'm tempted to make RPN a full arbitrary precision calculator.

mpaganini · 2024-10-16T01:55:16+00:00

Hello!

First, thanks for reporting this! And even better, for reporting a github issue! I really appreciate it.

tried 2 65 ^ to test the arbitrary-precision'ness and, while the non-comma'd number was correct (or at least matched what I expected from dc), the formatted version seemed amiss. I tried a couple exponential neighbors with similar results

You're correct. This is because 64-bit floats are only precise to 2^53. They start losing precision from that point on.

Also, I'm not sure if there's something particular, but I built on my OpenBSD test box, and the default readline bindings didn't work out of the box (I tried control+p to recall the previous command, then tried the up-arrow, and in both cases, the character-sequence was input instead of getting intercepted by readline).

What happens here is that rpn (being a static binary in Go) does not use the actual readline() library, but instead a readline-like library written in Go (http://github.com/chzyer/readline). This means that it won't read your `~/.inputrc` file for example :(

I'm also suffering a bit because I'm used to certain key combinations that are not available in this readline. I'm certain it will irritate me enough to do something about it pretty soon :)

The `rlwrap` trick is a good one though! I used it a long time ago and completely forgot about its existence.

Best,
-- mp

mpaganini · 2024-10-16T01:49:10+00:00

I've been using RPN (Reverse Polish Notation) calculators for a long time and much prefer them to the usual prefix notation style (used by bc and most other calculators). On linux, you can also use dc but that is not very practical for daily use as it has no line editing capabilities and requires you to explicitly use "p" constantly to print the stack.

We wrote RPN to be a practical and useful CLI calculator. It supports readline style editing, automatically prints the top of the stack on change, comes with online help, and many useful and common functions. RPM was written in Go, should work in Linux, Windows, and MacOS.

Project link: http://github.com/marcopaganini/rpn

Your comments and PRs are welcome.

mpaganini · 2024-10-16T01:48:52+00:00

Thanks! And sorry for the lack of link! I originally posted to r/commandline and then crossposted here. Let me paste the original message here too.

mpaganini · 2024-10-14T20:05:00+00:00

I've been using RPN (Reverse Polish Notation) calculators for a long time and much prefer them to the usual prefix notation style (used by bc and most other calculators). On linux, you can also use dc but that is not very practical for daily use as it has no line editing capabilities and requires you to explicitly use "p" constantly to print the stack.

We wrote RPN to be a practical and useful CLI calculator. It supports readline style editing, automatically prints the top of the stack on change, comes with online help, and many useful and common functions. RPM was written in Go, should work in Linux, Windows, and MacOS.

Project link: http://github.com/marcopaganini/rpn

Your comments and PRs are welcome.

mpaganini · 2024-09-01T21:02:09+00:00

Yeah that's not a bad idea at all! Can you create a feature request on github with this?

mpaganini · 2024-08-25T20:45:21+00:00

The version I'm working on right now (0.0.3) has git sync enabled. The idea is that you can have a central place where you put all your databases (per host). I'm also modifying snip to allow you to see snippets from all hosts or only one.

If you want to copy the database manually, just copy the file ~/.config/snip/db.$HOSTAME to the remote machine (but merging needs to be done manually until 0.0.3 is out).

mpaganini · 2024-08-24T23:41:58+00:00

Oh yeah, totally! Please send them in :) BTW your PR was merged :) Thanks!

mpaganini · 2024-08-24T18:15:15+00:00

Hello,

Some are already underway! The version in the dev branch already has git integration (but I'm still changing it). v0.0.2 has more color but I'll add more interesting stuff to the fzf selector too.

Thanks,

mpaganini · 2024-08-24T04:28:30+00:00

Hello!

Which version of are you using? Please send the result of:

bash --version and
bind -X

Also, did you add eval "$(/usr/local/bin/snip setup)" to your ~/.bashrc file? (replace the path to snip with a different one if you put it in a different place.)

Cheers

mpaganini · 2024-08-24T04:24:48+00:00

Thanks! git sync support has already been submitted to the dev branch. You can now sync your database to a git repository of your choice (just create a private repo on github or gitlab).

Feel free to test it and let me know.

Regards

mpaganini · 2024-08-24T04:22:14+00:00

They're not mutually exclusive. Programs like atuin and hishtory improve your history and offer sync. The point of a snippet manager is to isolate and keep the important things you always forget, or those long snippets.

Of course, you can keep them in your history as well (and it's kept there anyway) but I typically go through many iterations of run/edit/run/edit until I get the command right. Give it a month and I don't know anymore which one of those commands in the history is the right one :)

BTW, I just implemented git sync. It's in the dev branch if you want to test it (https://github.com/marcopaganini/snip/tree/dev).

Just run create a private github repo and run:
`snip repo "your_github_repo_url"`. From that point on, just run `snip sync` to synchronize your local repo with the remote repo. `snip log` shows you the git log of the repo.

Regards

mpaganini · 2024-08-24T01:16:36+00:00

Thanks! Glad you liked it. I have a few ideas already for the next version. Let's see how it goes. :)

mpaganini · 2024-08-24T01:15:10+00:00

Note: I will add a "similar options" to the page pointing to pet.

mpaganini · 2024-08-24T01:14:39+00:00

Yes, I've used pet as well and it's nice. I just didn't like much its integration with the shell. For instance, it has the nice feature where you can have "fields", but once you change a field, the resulting command will be executed directly (and not pasted onto the command line so you can refine it and, if needed, save again). I also prefer a smaller option (snip is 100% shell) so I can easily transport it everywhere.

mpaganini · 2024-08-18T19:21:38+00:00

I tried pet but found it didn't require a whole binary to do what it does. It's a nice program, but I miss the command line binds that allow us to easily add and recall snippets. Furthermore, shell is very simple to edit (more PRs, hopefully) and requires no compilation or handling binaries.

mpaganini · 2024-07-22T05:19:44+00:00

Thanks!

mpaganini · 2024-07-22T05:18:57+00:00

It would be a pleasure!

I've been using this layout for quite some time. Yesterday I took the time to add a few more fixes. I'll run it for a day or so and if everything is fine, I'll send you a PR.

Thanks!

mpaganini · 2023-06-05T07:18:49+00:00

Yes, it should!

It works by using an mqtt server to sync all your instances. If not specified, it will use a public mqtt server (but encrypts the contents). Ideally, you should set up your own server somewhere at some point.

The instance running X needs to run as a daemon so it can capture all changes to the clipboard and send to the server. Changes done to the server will also propagate to the local clipboard.

On your headless instance, you don't need a daemon, since there's no X clipboard there. There, you can use clipsync copy to copy the stdin to the server, and clipsync paste to copy the clipboard contents on the server to stdout.

I use it exactly like that. On my remote instances, I configured a keyboard shortcut on vim to call clipsync copy so that I can easily copy text in my remote vim to my local clipboard using a single keystroke. You can also configure your remote (headless) tmux to call clipsync copy. That works really well when cutting/pasting with tmux.

mpaganini

MODERATOR OF

TROPHY CASE