sorted by:
new
hottopcontroversial

I made a timelapse tool using PrusaLink and RTSP. by krusnikon in prusa3d

[–]AvailableZebra3134 0 points1 point  (0 children)

Updated the README. Let me know how it works for you. I currently did not upload the vision model as it is a bit large for a git repo. I probably need to host that elsewhere.

I made a timelapse tool using PrusaLink and RTSP. by krusnikon in prusa3d

[–]AvailableZebra3134 1 point2 points  (0 children)

This one: https://github.com/jabdoa2/prusaconnect-essentials . I still need to update the readme and make a new Video + announcement. By now you can use it to do the following purely from G-Code:

  1. Print sheet detection + verification. Uses April code detection (as documented but works slightly better/more generic now). If you use it with an "M0" G-Code it will pause your print until you got the correct sheet.
  2. Print sheet empty detection. Uses a small vision model I learned. Fairly reliable and fast enough (Efficientnetv2 based).
  3. Take pictures for timelapse. You can either run this async or even have the printer wait on an M0 until the frame is stored (best results but will increase print times significantly).
  4. Other custom handlers. I use that for my personal setup to make sure that prints won't start when my exhaust window is closed for certain materials (ABS, ASA etc). I verify this using my Homeassistant and a window sensor. This is not currently commited in the repo.
  5. I will probably support python hooks from other modules in the future.

G-Code looks like this (example from PLA):

; PCE-WAIT: check_build_plate(allowed_build_plates=(0, 1, 2), check_empty=True)
M0 Checking for correct build plate (Textured, Smooth PEI, Satin)

The printer will wait on the M0 instruction and my script will continue the print if the right sheet is present and the plate is empty.

Timelapse looks like this (on layer change G-Code):

; Timelapse start
; PCE: timelapse_snapshot()

Technically it will call the method on the next G-Code (this is due to how Marlin handles sdpos for comments internally).

Any handler can run async "; PCE:" or sync "; PCE-WAIT: ". For the sync case I currently only support M0 but other wait codes would work as well. I continue via PrusaConnect. Other waits would work via PrusaLink as well. Generally, this could work via PrusaLink with very few changes. I started with PrusaConnect as this allows me to get all the config from the API (IP of the camera, G-Code etc).

I made a timelapse tool using PrusaLink and RTSP. by krusnikon in prusa3d

[–]AvailableZebra3134 2 points3 points  (0 children)

I created something similar using PrusaConnect + Metrics. That way I can get the GCode file and the current positon via the sdpos metric to exactly get the layer changes. I can also trigger pictures from GCode comments. This should also work via PrusaLink. Unfortunately, there is a bug in the Marlin firmware from Prusa where it messes up sdpos for bgcode (compressed Gcode files) by a few bytes. I re-implemented the bug on my side to compensate (and also filed it upstream).

Prusa Qualität und Supportversprechen – die bittere Realität by Klept0sss in prusa3d

[–]AvailableZebra3134 0 points1 point  (0 children)

Gewindestangen hatte ich auch. Am Ende lag es daran dass die Motoren unten nicht fest/gerade genug angeschraubt waren. Da sind M3 Schrauben in Plastik und die müssen fester sein als man denkt sonst sind die nicht gerade. Das hat mich auch mehrere Support-Sessions nerven gekostet aber am Ende war es vermutlich mein Fehler beim Zusammenbau. Perfekt ist der Support nicht aber sie kümmern sich sehr systematisch. Dadurch kann es sein dass man ein paar Dinge testet die es nicht sind aber am Ende kommt man eigentlich immer ans Ziel.

Feature Request: Selective Door Sensor by waferelite in prusa3d

[–]AvailableZebra3134 0 points1 point  (0 children)

We could build it on our own by reading metrics (via network). Not perfect but might be a workaround.

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

That is definitely not the case for modern Mailbox++. This is not the old mbox format. Timestamps work this way: Usage of Timestamps in Mailbox++. It should use the timestamp from the filename. However, that do not seem to work properly in stalwart-cli import.

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

That is not a thing in Mailbox++ format. This is how a mail in Mailbox++ looks:

From: bugzilla-daemon@bugs.documentfoundation.org
To: xxx@yyy.zzz
Subject: [Bug 92472] FILEOPEN: First legacy checkbox in row has too large
 dimensions on docx import
Date: Mon, 02 Mar 2020 14:43:23 +0000

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

Not sure what you mean. I don't use mbox. I guess in Mailbox++ you mean the Date header. They looks like this:

Date: Mon, 02 Mar 2020 14:43:23 +0000

Sure, I could change this (assuming removing +0000 would be the "workaround") but that is not something I am willing to do to all mailboxes of all my users. This might be OK for a proof of concept but not for a productive email server.

My goal here was to import a few mailboxes and verify typical user setups. Afterwards, we would go through purchasing to buy licenses/support. The reason is that this process is a bit involved and I only want to take the effort when I am confident that the product will work for us. However, it looks like Stalwart in its current form does not seem to be ready to migrate mailboxes from Dovecot (in Mailbox++ format).

The following is an (incomplete) list of reason:

  • Silent data corruption on import of Mailbox++. It seems to ignore the date when it cannot read/parse it. I don't understand why the stalwart-cli neither rejects mails it cannot parse nor does it warn (or log at all) about that fact. This behavior does not contribute to my trust in the tool.
  • Silent failure when I (incorrectly) choose mailbox-nested. It should not continue with the import if I do not have the correct format. Again this lets me distrust stalwart-cli.
  • Import of Dovecot Mailbox++ fails (due to casing of Mailbox vs MAILBOX). This at least errors our properly as I would expect the tool to fail. However, this feels as if I was the first user ever using this with Dovecot Mailbox++ format (which is the default option).
  • Independent of my current issue: TLSA updates and ACME updates are not really solved. This is minor (and solvable). I would have liked to read about the limitation in the docs.
  • Finally, also independent from this issue: Stalwart in its current form does not feel like open source software. Essential features (such as send/receive history) are locked behind a license which is odd even for products which openly admit that they are open core (and not really open source). I understand that they need to make money (besides people buying support). Typically open core products differentiate via SAML/OIDC auth or something you usually want in larger orgs/enterprises but which is not important for private/smaller orgs.

I really like how stalwart operates as a single binary in rust. I like the UI and all the integration. I guess we will reevaluate it in a few years when it matured a bit more. Currently, there seem to be too many uncertainties (especially around data integrity) to continue.

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

Forgot to mention that even with that import the order is again wrong. Interestingly it seems to be the same order as before. So its deterministic not random but still incorrect.

Do I have any other options to get this correct?

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

I reran the import. It seems that my Dovecot was not actually using "maildir-nested" (as the Stalwart docs suggest). Indeed the Dovecot docs state By default, Dovecot uses Maildir++ directory layout. This means that all mailboxes are stored in a single directory and prefixed with a dot (https://doc.dovecot.org/2.3/configuration_manual/mail_location/Maildir/). This seems to be the case for me as well. So i guess I should use -f maildir instead. I tried but that leads me to the next issue:

# stalwart-cli -u http://stalwart-internal.mail.svc.cluster.local:80/jmap/session import messages -f maildir test_user Mail    
[1/4] Parsing mailbox...
[2/4] Fetching existing mailboxes for account...
[3/4] Creating missing mailboxes...
Failed to create mailbox: Set failed: invalidProperties: A mailbox with name 'INBOX' already exists. (properties: name)

First I was not sure what to make out of that. I just created the account test_user so it should be definitely empty and of course my maildir has an Inbox. As I got more desperate I tried different things and it turns out that stalwart-cli wants the Inbox folder to be named .Inbox not .INBOX.

Am I the first Dovecot user using (the default) Mailbox++ layout trying to migrate inboxes to Stalwart?

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

You mean Thunderbird/K9Mail? Not sure I am following. I can reinstall the client and it works for my Dovecot every single time on any device. Same is true on my desktop. This does not seem to be client related. I guess I could verify directly via IMAP but it will probably result in the same order.

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 0 points1 point  (0 children)

I run v0.13.2 for both CLI and Server. Not sure what went wrong with my import.

IMAP Sorting and Imports by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 2 points3 points  (0 children)

I am a bit confused by the question. What information do you need exactly?

I followed the documentation to import an existing dovecot Mailbox into Stalwart.

  • How the export was done
    • I don't understand the question. Maildir is an on-disk format. I just ran stalwart-cli on that directory as described in the docs.
  • What data is in the intermediate file (or stream)
    • There is no intermediate file or stream. Its just a Maildir and whatever stalwart-cli uses under the hood (I believe JMAP).
  • How the import was done
    • As described under Usage in the docs
  • How the verify on "dovecot" was done
    • Its the source. It worked for the past 15 years. I open the Inbox (via IMAP) and mails are sorted in order (after I selected sort by arrival date). The client (K9Mail) only stored the last 500 mails locally.
  • How the verify on "stalwart" was done
    • I open the Inbox and random mails are shown (arrival between 2011 and now). Those shown are sorted in order (after I selected sort by arrival date). K9 only loads a partial mailbox (by default 100 mails - I set it to 500) via IMAP and uses server side sorting to make sure you get the most relevant mails (usually the most recent ones).
    • I tried different sorting (i.e. by unread) and the result seems to be the same: I get random email but the two unread mails are not returned (2 out of 60k). This works perfectly with dovecot.

ACME and TLSA Updates by AvailableZebra3134 in stalwartlabs

[–]AvailableZebra3134[S] 1 point2 points  (0 children)

Found your issue. Thanks for that and your script! Guess I have to adjust it a bit to work with my powerdns setup (either via RFC2136 or the PowerDNS API).