UPS recommendation for TP-Link TL-SG105E switch,need at least 6 hours backup

UPS recommendation for TP-Link TL-SG105E switch,need at least 6 hours backup

I’m looking for a UPS/power backup solution for my TP-Link TL-SG105E 5-Port Gigabit Easy Smart Switch.

I need the switch to stay powered during power cuts for at least 6 hours, preferably longer if possible. The switch uses a small DC adapter, so I’m wondering whether a mini DC UPS/router UPS helps it

Edit : I’m running a Raspberry Pi server, and both my router and Raspberry Pi already have UPS backup. The only device that doesn’t have a UPS is this network switch.

I’m also a student, so I can’t really afford a large or expensive power backup solution. I’m looking for something affordable that can keep just this switch running for at least 6 hours during a power cut.

u/Tutyfruiity — 9 days ago

How to access my VPS through my collage wifi

So I have a VPS, and I self-host a lot of services, but I am unable to access my Jellyfin and Navidrome, etc through my college Wi-Fi since they use Fortinet, and all the services I hosted are configured in a way that I can access them via Tailscale. Is there any way to access my service without making it public (mobile data is weak in my college area)

reddit.com
u/Tutyfruiity — 3 months ago

How to access my VPS through my collage wifi

So I have a VPS, and I self-host a lot of services, but I am unable to access my Jellyfin and Navidrome, etc through my college Wi-Fi since they use Fortinet, and all the services I hosted are configured in a way that I can access them via Tailscale. Is there any way to access my service without making it public (mobile data is weak in my college area)

reddit.com
u/Tutyfruiity — 3 months ago

PC Build for My Younger Sister Until 12th Standard

reddit.com
u/Tutyfruiity — 4 months ago

Partime job ppls help me 😭🙏🏽

So njan oru textile shop ill partime job nokanu(4hr/day 4days off monthly)and they asked "whats the expected salary that im looking?". idk what to say pls help me 😭🙏🏽🙏🏽

reddit.com
u/Tutyfruiity — 5 months ago

I've been building a multi-agent personal finance tracker in n8n (Telegram → main agent → sub-agents → MongoDB). The sub-agent responsible for DB retrieval is giving me wrong/hallucinated results

Architecture:

Main agent — classifies user intent, picks the correct sub-agent, passes structured instructions (intent type, user_id, date range, filters)

MongoDB sub-agent — receives that structured input, builds + runs an aggregation pipeline, returns structured JSON back to main agent

DB: MongoDB, collection: transactions

What I've already done in the sub-agent system prompt

  1. Full schema provided — every field, its type, allowed values, and constraints (e.g. amount_paise is the only money field, divide by 100 for INR, user_id is always an integer)
  2. 15 intent types defined with explicit routing rules (e.g. monthly_summary, person_cash_flow, investment_tracking, savings_rate, comparison, etc.) and clear disambiguation rules like "if a specific person's name appears → always person_cash_flow, never any other transfer intent"
  3. Pre-built pipeline templates for every intent — the agent isn't meant to write pipelines from scratch. Pipeline A through O are all written out. It just fills in variables like user_id, year, month
  4. Hard arithmetic rules — the agent is forbidden from doing any INR math itself. All division happens inside $divide:["$amount_paise",100] within the pipeline. Only 3 post-pipeline calculations are permitted (savings_rate, savings_inr, comparison delta)
  5. Strict $match ordering — user_id must always be the first field in every $match
  6. Timeframe rules — agent uses pre-computed year/month/day/week_key integer fields, never parses date strings
  7. Empty result handling — explicit fallback rules for every pipeline type (empty [] → return zeroed-out JSON, not an error or hallucination)
  8. Strict output format — output is JSON only, schema defined per intent, no markdown, no explanation
  9. Optional filter injection rules — how to handle amount ranges, platform normalization (always lowercase), regex for item_name/note search, etc.

Despite all this, the agent still:

  • Reports transactions as non-existent when they clearly exist
  • Returns wrong totals (e.g. investments total comes back as 0 when there are matching records)
  • Occasionally returns a well-formatted JSON response with numbers it just made up
  • Sometimes runs the right pipeline intent but with a broken $match (my suspicion)

Example(a valid case):

Main agent passes:

Find total investment transactions for May 2026, user_id, aggregation type: monthly_summary, filter: type=investment, date range: 2026-05-01 to 2026-05-31

Sub-agent returns a valid-looking monthly_summary JSON with investments: {total_inr: 6798, count: 1}

reddit.com
u/Tutyfruiity — 5 months ago
▲ 6 r/n8n

I've been building a multi-agent personal finance tracker in n8n (Telegram → main agent → sub-agents → MongoDB). The sub-agent responsible for DB retrieval is giving me wrong/hallucinated results

Architecture:

Main agent — classifies user intent, picks the correct sub-agent, passes structured instructions (intent type, user_id, date range, filters)

MongoDB sub-agent — receives that structured input, builds + runs an aggregation pipeline, returns structured JSON back to main agent

DB: MongoDB, collection: transactions

What I've already done in the sub-agent system prompt

  1. Full schema provided — every field, its type, allowed values, and constraints (e.g. amount_paise is the only money field, divide by 100 for INR, user_id is always an integer)
  2. 15 intent types defined with explicit routing rules (e.g. monthly_summary, person_cash_flow, investment_tracking, savings_rate, comparison, etc.) and clear disambiguation rules like "if a specific person's name appears → always person_cash_flow, never any other transfer intent"
  3. Pre-built pipeline templates for every intent — the agent isn't meant to write pipelines from scratch. Pipeline A through O are all written out. It just fills in variables like user_id, year, month
  4. Hard arithmetic rules — the agent is forbidden from doing any INR math itself. All division happens inside $divide:["$amount_paise",100] within the pipeline. Only 3 post-pipeline calculations are permitted (savings_rate, savings_inr, comparison delta)
  5. Strict $match ordering — user_id must always be the first field in every $match
  6. Timeframe rules — agent uses pre-computed year/month/day/week_key integer fields, never parses date strings
  7. Empty result handling — explicit fallback rules for every pipeline type (empty [] → return zeroed-out JSON, not an error or hallucination)
  8. Strict output format — output is JSON only, schema defined per intent, no markdown, no explanation
  9. Optional filter injection rules — how to handle amount ranges, platform normalization (always lowercase), regex for item_name/note search, etc.

Despite all this, the agent still:

  • Reports transactions as non-existent when they clearly exist
  • Returns wrong totals (e.g. investments total comes back as 0 when there are matching records)
  • Occasionally returns a well-formatted JSON response with numbers it just made up
  • Sometimes runs the right pipeline intent but with a broken $match (my suspicion)

Example(a valid case):

Main agent passes:

Find total investment transactions for May 2026, user_id, aggregation type: monthly_summary, filter: type=investment, date range: 2026-05-01 to 2026-05-31

Sub-agent returns a valid-looking monthly_summary JSON with investments: {total_inr: 6798, count: 1}

reddit.com
u/Tutyfruiity — 5 months ago