The quality of a RAG system isn't defined by the moments it answers correctly. It's defined by whether it can recognize the moment it shouldn't answer at all and stay quiet. Most RAG implementations lack this second ability: ask anything, and they hand you something. This post walks through a retrieval layer that bakes "how much can we trust this answer" into the pipeline itself, and when needed says "I don't have information on this" without ever calling the LLM.

The examples come from a self-hosted RAG platform running in production; the language is Python and the database is PostgreSQL + pgvector.

The problem: high similarity, wrong answer

The classic RAG flow is simple:

# Naive RAG: always produces an answer
async def naive_answer(db, query: str) -> str:
    embedding = await embed(query)
    chunks = await vector_search(db, embedding, top_k=5)  # always returns 5
    context = "\n\n".join(c.content for c in chunks)
    return await llm.chat(
        system=f"Answer using the following context:\n{context}",
        user=query,
    )

Embed the query, pull the nearest k chunks, stuff them into the prompt, ask the LLM. This flow has a silent flaw. vector_search always returns "the nearest k results," but it never asks "is anything actually close enough?" Even when the knowledge base contains nothing about the topic, the nearest k chunks still come back and land in the prompt. Notice that naive_answer can never say "I don't know" under any condition; its return type doesn't even make that possible.

The conceptual mistake here is treating cosine similarity as a quality signal. Similarity is a ranking signal: is result A more relevant than result B? It answers that well. But "is result A relevant enough to answer this question?" is a different question, and similarity alone doesn't answer it. The "best" chunk at 0.65 cosine distance can still be entirely irrelevant in absolute terms.

The result is RAG's most dangerous mode: the model builds extremely confident sentences on top of weak context. The user never sees the source, only a fluent and wrong answer.

The fix is not to delegate "confidence" to the prompt (saying answer only based on the context). That instruction helps, but it's a weak line of defense; it relies on the model complying. Far more robust is to measure confidence in the retrieval layer and never go to the LLM when it's low.

A two-tier threshold

A single threshold doesn't solve this, because we're making two distinct decisions:

1. Is this chunk worth putting into the context? (noise cleanup)
2. Should we even attempt an answer with the context we have? (the answer decision)

Different jobs, different thresholds:

# Minimum confidence for a chunk to enter the context (filters low-quality matches)
MIN_CHUNK_CONFIDENCE = 25.0
# If average confidence is below this, skip the LLM and reject directly
MIN_CONFIDENCE_GATE = 40.0

First we convert cosine distance into a 0-100 chunk score:

def _distance_to_confidence(distance: float, max_dist: float = 0.65) -> float:
    if distance <= 0:
        return 100.0
    if distance >= max_dist:
        return 0.0
    return round(max(0, (1 - distance) * 100), 1)

A linear transform; not a sophisticated calibration, and deliberately so. max_dist is a ceiling: anything beyond that distance counts as zero and is already dropped during retrieval. The goal here isn't to produce a true probability, but a consistent scale that's comparable against thresholds. On that scale, 25 ("don't put it in the context") and 40 ("don't answer at all") become meaningful boundaries.

Hybrid retrieval: vector + BM25, fused with RRF

Vector search captures meaning but is weak on exact matches: a product code, a proper name, an SKU doesn't resemble something semantically "close," it appears verbatim where it appears. BM25 keyword search is the opposite: strong on exact matches, weak on meaning. Using both is natural, but there's a problem: their scores aren't comparable. A cosine distance and a PostgreSQL ts_rank are not on the same scale and can't be summed.

Each search produces its own ranked list. The vector side, via pgvector and cosine distance:

distance_expr = Chunk.embedding.cosine_distance(query_vector)
stmt = (
    select(Chunk, distance_expr.label("distance"))
    .where(Chunk.embed_id == embed_id)
    .where(Chunk.chunk_type == "child")
    .order_by(distance_expr)        # smaller distance = more relevant
    .limit(top_k)
)

The keyword side, via PostgreSQL full-text search over a prefix-matching tsquery:

# "return policy" -> "return:* & policy:*"  (prefix also matches "returns", "policies")
ts_query = func.to_tsquery("simple", func.unaccent(prefix_expr))
rank_expr = func.ts_rank(Chunk.search_vector, ts_query)

distance (near 0 = good) and ts_rank (large = good) point neither in the same direction nor on the same scale. The fix is to fuse ranks, not scores: Reciprocal Rank Fusion.

def _reciprocal_rank_fusion(
    vector_results: list[tuple[str, float]],
    keyword_results: list[tuple[str, float]],
    k: int = 60,
) -> list[str]:
    scores: dict[str, float] = {}
    for rank, (chunk_id, _) in enumerate(vector_results):
        scores[chunk_id] = scores.get(chunk_id, 0) + 1.0 / (k + rank + 1)
    for rank, (chunk_id, _) in enumerate(keyword_results):
        scores[chunk_id] = scores.get(chunk_id, 0) + 1.0 / (k + rank + 1)
    return sorted(scores.keys(), key=lambda x: scores[x], reverse=True)

The elegance of RRF is that it ignores the raw score value entirely. It uses only the rank: a chunk near the top of both lists gets a high total, one that appears in only a single list gets less. A concrete example (k=60):

Vector order:   [A, B, C]      Keyword order:  [C, A, D]

A: 1/(60+0+1) + 1/(60+1+1) = 0.01639 + 0.01613 = 0.03252
C: 1/(60+2+1) + 1/(60+0+1) = 0.01587 + 0.01639 = 0.03226
B: 1/(60+1+1)              = 0.01613
D: 1/(60+2+1)              = 0.01587

Fused order: [A, C, B, D]

Even though neither A nor C tops a single list, they rise to the top because they appear in both. The constant k=60 (from the original RRF paper) softens the influence of the leading ranks; as k grows, the gaps between ranks shrink. This approach is scale-independent and resistant to outlier scores, which makes it the most practical way to combine two heterogeneous search systems.

After the fused ranking we filter out low-quality chunks, with one exception:

# Hand-written Q&A always ranks first, exempt from the minimum confidence filter
training_chunks = [c for c in chunks if c.chunk_metadata.get("source") == "training_data"]
doc_chunks = [c for c in chunks if c.chunk_metadata.get("source") != "training_data"]

# Drop document chunks below the threshold
doc_chunks = [c for c in doc_chunks if score_map.get(c.id, 0) >= MIN_CHUNK_CONFIDENCE]

Curated (hand-prepared) answers are exempt from this filter, and from the rejection gate we'll see next. The reasoning: if someone wrote the correct answer to this question by hand, the system's statistical confidence calculation shouldn't override that human decision.

The rejection gate: never calling the LLM

This is the real decision. If average confidence is below the threshold, we don't build a prompt and go to the LLM; we reject directly:

avg_confidence = _calc_final_confidence(chunks)
has_training_data = any(c.chunk_metadata.get("source") == "training_data" for c in chunks)

# If confidence is too low, skip the LLM. Never reject when training data matches.
if not has_training_data and avg_confidence is not None and avg_confidence < MIN_CONFIDENCE_GATE:
    yield f"{json.dumps(meta, ensure_ascii=False)}\n"
    yield "[REJECTION]"
    yield await _get_rejection_message(embed, lang)
    return

This has three concrete benefits:

• Zero hallucination risk. Weak context never reaches the model, so the model can't build on it.
• Token savings. No chat completion call is made for a query that will be rejected. At high volume this is a serious cost line.
• Faster response. Rejection skips the slowest step (LLM generation), so it returns instantly.

Since the stream is SSE, we mark the rejection with a [REJECTION] sentinel; when the frontend sees it, it renders the response as a "no information" state instead of a normal answer. From the client's side, a rejected query looks like this:

{"sources": [], "response_time_ms": 48, "avg_confidence": 22.0}
[REJECTION]
I don't have enough information about this topic in my knowledge base.

Note response_time_ms: 48: because the LLM was never called, the response returned in under 50 ms. For comparison, the first token of an accepted query usually takes 800-2000 ms. The rejection message itself is chosen by query language: first a fixed fallback dictionary, then LLM translation if needed.

_FALLBACK_REJECTION = {
    "tr": "Bu konuda bilgi tabanımda yeterli bilgi bulunmamaktadır.",
    "en": "I don't have enough information about this topic in my knowledge base.",
    "de": "Zu diesem Thema habe ich nicht genügend Informationen in meiner Wissensdatenbank.",
}

Final confidence is not the retrieval score

The confidence score we show to the user and to analytics is not the raw cosine score. This is a deliberate separation: the raw retrieval score is an internal metric, while the confidence shown to the user is a UX decision. Telling a user "42% confidence" is misleading, because that number isn't confidence in the sense they understand.

def _calc_final_confidence(chunks, is_rejected=False):
    scores = [getattr(c, "_confidence", None) for c in chunks]
    scores = [s for s in scores if s is not None]
    if not scores:
        return round(10.0 if not is_rejected else 5.0, 1)
    best_score = max(scores)
    if is_rejected:
        # Chunks found but couldn't answer -> 20-50 range
        return round(20 + (best_score / 100) * 30, 1)
    # Chunks found and answer given -> 70-100 range
    normalized = min(1.0, max(0.0, (best_score - 20) / 60))
    return round(70 + normalized * 30, 1)

The score first lands in a tier based on the outcome: answer given (70-100), chunks found but rejected (20-50), no chunks at all (5-10). The raw score of the best chunk only fine-tunes within that tier. This way the user interprets the number correctly: 80 really is "good," 35 really is "questionable."

How to tune these numbers

25, 40, 0.65, k=60 are not universal truths; they're values that settled in for our domain. The practical way to calibrate them for your own system:

1. Log avg_confidence on real queries.
2. Hand-label correct and incorrect answers, and plot the confidence histogram of each group.
3. Put the gate where the two distributions intersect.

In practice, a simple sweep over the logged data shows the real cost of the threshold:

# Evaluate candidate gate values over labeled historical queries
def evaluate_gate(samples, gate):
    # samples: [(avg_confidence, was_correct), ...]
    rejected = [s for s in samples if s[0] < gate]
    answered = [s for s in samples if s[0] >= gate]
    false_rejects = sum(1 for c, ok in rejected if ok)      # rejected, but could have answered correctly
    hallucinations = sum(1 for c, ok in answered if not ok)  # answered, but wrong
    return false_rejects, hallucinations

for gate in (30, 35, 40, 45, 50):
    fr, hl = evaluate_gate(samples, gate)
    print(f"gate={gate}: missed={fr}, hallucinations={hl}")

The two columns in the output are exactly the trade-off you want to manage: as gate rises, hallucinations drop and missed (needlessly rejected) queries climb. The domain's tolerance for error sets this balance. A medical or legal assistant should reject aggressively; a general FAQ bot can be more generous.

Closing

The path to better confidence in RAG is usually sought in "better embeddings," "a bigger model," "a smarter prompt." Yet the highest-leverage intervention is often simpler: teach the system to stay quiet. Instead of leaving confidence to the LLM's inner world, put a deterministic gate in the retrieval layer; that gate is cheap, testable, and predictable.

A system that can say "I can't answer this" earns more trust than one that answers everything. Because once a user gets a wrong-but-confident answer, they lose trust in the correct answers too.

CTO rolü dışarıdan genellikle cazip görünür. Karar veren, yönlendiren, teknolojiyi şekillendiren kişi… Ama işin içinde olunca fark ediyorsun ki bu koltuk aslında sürekli değişen bir denge oyunu. Teknik bilgi tek başına yetmiyor; liderlik, sabır, iletişim ve bazen de duygusal dayanıklılık gerekiyor.

Ekip yönetimi bu işin en karmaşık tarafı. Teknik problemler genelde çözülebilir; log tutarsın, debug yaparsın, sistemi ayağa kaldırırsın. Ama insanlarla çalışmak farklı. Herkesin motivasyonu, iletişim biçimi, önceliği birbirinden farklı. Bu çeşitlilik bir yandan inanılmaz bir güç, ama doğru yönetilmediğinde tüm ekibe yayılan bir probleme dönüşüyor.

Benim için dönüm noktası, iletişimi “problemi çözmek” için değil “anlamaya çalışmak” için kullanmam gerektiğini fark ettiğim andı. Eskiden biriyle fikir ayrılığı yaşadığımda hemen çözüm üretmeye odaklanırdım. Oysa çoğu zaman insanlar çözüm değil, duyulmak istiyor. Dinlemeyi öğrendikçe, anlaşılmamanın ne kadar yıpratıcı olduğunu da fark ettim.

Bir CTO olarak bazen “her şeyi bilmem” beklentisiyle karşılaşıyorum. Ekibin gözünde, yöneticilerin gözünde, hatta kendi iç sesimde bile… Oysa çoğu zaman bilmiyorum. Bilmemeyi kabul etmek, öğrenmeye açık kalmak, “bunu birlikte çözelim” diyebilmek en büyük rahatlama oldu. Bu tavır, ekipte güven yaratıyor. Çünkü kimse kusursuz bir liderin altında kendini rahat hissetmez; ama insani bir liderin altında büyümek ister.

Kriz Anlarında Sorumluluk Almak ve Stresi Yönetmek

Bu yolculukta unutamadığım anlardan biri, kritik bir servisin saatlerce cloud provider kaynaklı bir donanım problemi yüzünden devre dışı kaldığı gündü. Bir yandan müşterilerden mesajlar yağıyor, diğer yandan ekip panik içinde çözüm arıyordu. Akıllı saatim sürekli yüksek nabız bildirimi gönderiyordu. Eminim tüm ekip arkadaşlarım da aynı stresi yaşıyordu.

Herkesin gözü bir karar bekliyordu. “Yeni sunucuya geçişi başlatalım mı? Yoksa sorunun düzelmesini bekleyelim mi?” soruları arasında saniyeler uzuyordu. İçimden fırtınalar kopsa da sakin kalmam gerektiğini biliyordum. Zor bir kararla yeni sunucuya geçiş yaptık. İşe yaradı, ama asıl mesele teknik çözüm değil o anki duruştu. Gerginlik yerini odaklanmaya bırakmıştı. Sonra düşündüm: liderlik bazen doğru kararı bulmak değil, zor anda karar almayı ve o kararın sorumluluğunu üstlenmeyi bilmektir.

CTO olduktan sonra stresin bedensel etkilerini de daha net hissetmeye başladım. Yıllardır kontrol altında tuttuğum sedef hastalığım, özellikle yoğun dönemlerde yeniden alevlendi. O dönemde doktorum, “stres seni içeriden yakıyor” demişti. Gerçekten de haklıydı.

Kimi sabahlar uykusuzlukla, kimi akşamlar-geceler bitmeyen işlerle boğuşurken fark ettim ki liderlik sadece insan ve teknoloji yönetmek değil, kendi stresini de yönetebilmek. Bunun kolay bir reçetesi yok. Bazen işe birkaç dakika ara verip yürüyüş yapmak, bazen sessizce bir kahve içmek bile sistemi sıfırlayabiliyor. En azından ben kendimde bu küçük rutinleri oturtmaya çalışıyorum. Çünkü stresin biriktiği yerde, akıl da sezgi de körelmeye başlıyor.

Hatalarla Büyümek ve Öğrenmeye Devam Etmek

Teknik borç, bizim gibi ürün odaklı ekiplerde sürekli gölgede duran bir konu. Her yeni özelliğin arkasında bir miktar borç birikiyor. Eskiden bunu bir utanç kaynağı gibi görürdüm, şimdi daha gerçekçi bakıyorum: borç kaçınılmaz, mesele onu fark edip kontrol altında tutabilmek. “Büyüme mi, stabilite mi?” sorusunun cevabı hiçbir zaman net olmuyor.

Yıllar içinde şunu öğrendim: ekiplerin performansı bilgiyle değil, güvenle ölçülüyor. İnsanlar hata yapmaktan korkmadığında yaratıcılık ortaya çıkıyor. Bunu sağlamak için zaman zaman geriye çekilip “neden bu kadar baskı hissediliyor?” diye sormam gerekti. Çoğu zaman cevabı dışarıda değil, kendi davranışlarımda buldum. Aceleyle attığım bir yorum, toplantıda söylediğim bir kelime, bir fikri hızla kapatmam… Küçük detaylar, ekipte büyük yankılar yaratabiliyor.

Bugün geriye dönüp baktığımda, en çok büyüdüğüm anlar hatasız dönemler değil, tökezlediğim zamanlar oldu. Bir projede yanlış kişiye güvenmek, yanlış öncelik seçmek ya da bir çatışma anında sessiz kalmak… Bunların her biri beni yöneticilikten çok insan olarak olgunlaştırdı.

CTO olmak bazen bir maraton, bazen satranç, bazen de sadece fırtınayı atlatmak. Ama her durumda tek bir şey sabit kalıyor: bu yolculukta “bilmiyorum” diyebilmek ve öğrenmeye çalışmak çok değerli. Çünkü liderlik, her şeyi bilmek değil; öğrenmeyi hiç bırakmamaktır.

Hello, tech enthusiasts!

As a smart home user, I experience every day how automation simplifies our lives. Especially when you combine a flexible and powerful platform like Home Assistant with a technological marvel like a Tesla, the possibilities that emerge are truly fascinating. In this blog post, I'll share some automations I've created by integrating Tesla with Home Assistant and ideas on how you can enhance this process.

As you can see in the image, I've integrated all my Tesla's data into my Home Assistant via Tesla Fleet integration. This allows me to monitor a wealth of information in real-time, from battery level to whether the doors are open, and even the car's speed, all from a single screen. But the real fun begins when you start creating automations that simplify your life using this data.

Tesla Fleet Setup and Configuration

The Tesla Fleet integration in Home Assistant allows you to connect to your Tesla vehicles and access a wealth of data and control functionalities. To set it up, you'll typically need to:

1. Add the Integration: Navigate to Settings > Devices & Services > Add Integration in your Home Assistant instance.
2. Authenticate: You'll be prompted to log in with your Tesla account credentials. This process securely authenticates your access to your vehicle data.
3. Select Vehicles: After successful authentication, you can select which of your Tesla vehicles you want to integrate with Home Assistant.
4. Configure Entities: Once added, Home Assistant will create various entities for your vehicle, representing different aspects like battery level, charging status, location, doors, climate control, and more. These entities can then be used in dashboards, automations, and scripts.

This integration is the backbone for many advanced Tesla automations, providing the necessary data points to create intelligent routines.

Automation Suggestions

1. Arrival Automation: Let Your Garage Door Open Automatically

This automation ensures your garage door opens automatically as you approach home. Using just location data isn't enough, because you wouldn't want the door opening every time you get close. That's why I created a smarter scenario:

• Triggers:
  • When my car gets within 20 meters of home.
  • Or when my car has been in the "home" zone for 5 seconds.
• Conditions:
  • The driver is present in the seat (binary_sensor.tesla_is_user_present). This prevents the garage door from opening without me.
  • The car is in motion (sensor.tesla_speed is greater than 0).
  • The garage door is not already open.
• Actions:
  • First, I turn on the garage lights.
  • Then, I've added an AI-powered control mechanism. By analyzing the image from the garage camera, I check if there are any vehicles in the garage other than the ATV. This way, I prevent the door from opening and potentially hitting other vehicles inside.
  • If the AI's response is "No," I disarm the garage alarm and open the garage door.
  • If the response is "Yes," I receive a notification on my phone stating, "The garage door was not opened because another vehicle is in the garage."
  • Finally, after 5 minutes, I turn off the garage lights.

Thanks to this complex yet secure and user-friendly automation, I can drive directly into the garage without touching anything upon arrival.

2. Reverse Gear Automation: Effortless Exit from the Garage

This automation ensures the garage door opens automatically when you're backing out of the garage.

• Trigger:
  • When the Tesla's gear has been in "R" (Reverse) for 3 seconds.
• Conditions:
  • My location is within the "home" zone.
  • The driver is in the car.
  • The car's heading is oriented towards the garage door (sensor.tesla_heading is between 85 and 100 degrees).
  • The garage door is not already open.
• Action:
  • When all conditions are met, the garage door automatically opens.

This automation provides significant convenience when exiting the garage and greatly simplifies the maneuvering process.

3. Battery Level Alert: Never Forget to Charge

Battery level is critical for electric vehicles. This simple automation notifies me when my car's charge level drops below a certain threshold:

• Trigger:
  • When the Tesla's battery level (sensor.tesla_battery_level) drops below 21%.
• Action:
  • A notification is sent to my phone with the title "Tesla Model Y Charge Below 20%" and the message, "Tesla Model Y's charge has dropped below 20%. Please charge as soon as possible!"

This way, the risk of forgetting to charge is eliminated, and I don't experience the stress of running out of power.

What Else Can Be Done?

With the flexibility offered by Home Assistant and the richness of Tesla data, you can create many more automations by pushing your imagination. Here are a few ideas:

• Tracking your Tesla when it travels a wide area: You can set up notifications for when it leaves a specific geographic area (geo_fence). For example, if your child takes the car and moves outside a designated zone, you'll be notified instantly.
• Closing windows based on weather: Using rain sensor data, you can ensure that windows close automatically if they are detected to be open. You don't even have to be home!
• Automatic locking of doors and trunk: When you park the car and leave home, you can set up an automation to ensure the doors and trunk are locked.
• Notification when charge limit is reached: You can set up a notification for when the charge limit is reached (sensor.tesla_charge_limit), allowing you to take action to stop charging.

You too can create automations that simplify your life with Home Assistant and Tesla integration, taking your smart home experience to the next level. Do you have any other ideas on this topic? Don't forget to share them in the comments!

Tesla cars have revolutionized the automotive world with their technology and driving experience. However, beyond the standard features your car offers, it's natural to want to understand your driving habits, charging efficiency, and vehicle performance in greater depth. This is precisely where Teslamate comes in. Teslamate is a powerful, open-source project that allows you to locally store your Tesla's data and provides you with comprehensive analyses.

In this post, we'll explore what Teslamate is, why you should use it, and most importantly, how to easily set it up with Docker, step by step.

What is Teslamate and Why Use It?

Teslamate retrieves data from your vehicle via Tesla's API (location, speed, battery status, charging information, driving statistics, etc.) and securely stores it on your own local server. This means:

• Your Privacy is Protected: Your data is stored in an environment you control.
• Detailed Analytics: You can visualize your driving patterns, energy consumption, charging costs, and past trips through graphs and maps.
• Performance Tracking: Gain valuable insights into your car's battery health and charging efficiency.

Setting Up Teslamate with Docker: A Step-by-Step Guide

The most practical way to install Teslamate is by using Docker. Docker allows you to run applications in their own isolated environments, simplifying complex setup processes.

Prerequisites:

Before you begin, make sure you have the following:

• Docker: (If you are new to Docker, see Installing Docker and Docker Compose).
• A Machine that's always on: This can be a computer, a Raspberry Pi, a mini PC, or a VPS running in the cloud. It needs to be operational 24/7 so Teslamate can continually fetch data.
• Sufficient RAM: At least 1 GB of RAM is required for a successful installation, but we recommend having at least 2 GB for optimal operation.
• External Internet Access: To communicate with tesla.com and retrieve data.

Setup Steps:

1. Download the Teslamate Docker Compose File

Typically, Teslamate's GitHub repository contains a ready-to-use docker-compose.yml file. You can start by downloading this file.Bash

curl -L https://raw.githubusercontent.com/teslamate-io/teslamate/master/docker-compose.yml -o docker-compose.yml

2. Database Configuration (Optional but Recommended)

Teslamate uses a PostgreSQL database to store data. The docker-compose.yml file includes settings for the database. For security and data persistence, you can customize the database information as well (e.g., POSTGRES_PASSWORD).

# Relevant section from docker-compose.yml (example)
environment:
  - TESLA_EMAIL=your_email@example.com
  - TESLA_PASSWORD=your_password
  # ... other settings

3. Start Teslamate

After saving the file, open your command prompt in the directory where the docker-compose.yml file is located and run the following command:Bash

docker compose up -d

This command will start Teslamate and its dependent services (like the database) in the background.

Once Teslamate starts:

• Open the web interface http://your-ip-address:4000
• Sign in with your Tesla Account

Accessing the Dashboards:

1. Teslamate Dashboard: Once all services are running, you can access the core Teslamate interface, which shows direct data feeds and basic analytics, by navigating to http://your-ip-address:4000 in your browser.
2. Grafana Dashboards: For more advanced and customizable metrics visualization, Grafana is used. Access the Grafana dashboards by navigating to http://your-ip-address:3000 in your browser. The initial login credentials are often admin/admin, but you'll be prompted to change these for security. You'll find pre-configured dashboards here that leverage the data collected by Teslamate.

What Can You Do with Teslamate?

After setup, you'll get to know your car better with the features Teslamate offers:

• Teslamate Interface (Port 4000): Quick overview of recent trips, charging status, and direct data logs.

• Grafana Dashboards (Port 3000):
  • Trip History: Detailed mapping and analysis of all your drives.
  • Charging Analysis: In-depth reports on charging times, costs, and charger performance.
  • Energy Consumption: Average Wh/km values and consumption differences by driving mode.
  • Battery Health: Comprehensive tracking of your battery's status and degradation over time.

Conclusion

Teslamate, paired with Grafana for advanced visualization, is a fantastic tool for Tesla owners, enabling them to use their vehicles more consciously through data. Thanks to Docker, its installation is greatly simplified. With Teslamate and Grafana, you can fully unlock your car's potential and gain deep insights into its performance.

With these initial steps, you've taken control of your car's data and set up powerful tools for analysis. In our upcoming posts, we'll delve deeper into optimizing your Grafana dashboards and exploring advanced Teslamate features.

Have you tried setting up Teslamate and Grafana? Don't forget to share your experiences and any questions in the comments below!

Docker is a helpful tool for making software development easier. In this guide, we'll show you how to set up a development environment for Ruby on Rails using Docker. We'll also make sure your data stays secure, even if you stop or remove containers. We'll be working with PostgreSQL and Redis databases, and we'll assume you're getting a project from GitHub.

Installing Docker

Start by installing Docker on your computer. Docker Desktop is easy to use and works on both Windows and macOS. Get it from the official Docker website. I personally recommend OrbStack over Docker Desktop. (MacOS only yet)

Docker Compose

Docker Compose is a handy tool for managing applications with multiple parts. It lets you describe everything in one file. Here's a simpler docker-compose.yml for setting up Ruby on Rails with PostgreSQL and Redis, and making sure your data stays safe:

version: '3'
services:
  web:
    image: ruby:latest
    ports:
      - "3000:3000"
    volumes:
      - ./app:/app
    depends_on:
      - db
      - redis
  db:
    image: postgres:latest
    environment:
      POSTGRES_DB: myapp_development
      POSTGRES_USER: myapp_user
      POSTGRES_PASSWORD: myapp_password
    volumes:
      - pg_data:/var/lib/postgresql/data
  redis:
    image: redis:latest
    volumes:
      - redis_data:/data
volumes:
  pg_data:
  redis_data:

In this simpler setup, we've introduced volumes (pg_data for PostgreSQL and redis_data for Redis) to make sure your data stays safe.

git clone https://github.com/yourusername/your-rails-project.git

Next, navigate to your project directory:

cd your-rails-project

Creating a Ruby on Rails Application:

Now, let's consider you are pulling an existing Ruby on Rails project from GitHub. Clone the project into your desired directory.

Configuring PostgreSQL and Redis

In your Rails project, you'll need to configure your database.yml and any other environment-specific configuration files to work with the Docker containers for PostgreSQL and Redis. Ensure you have the correct host, username, password, and database name settings.

Dockerizing Your Ruby on Rails Application:

For your Rails application to work seamlessly with Docker, you'll need to create a Dockerfile in the root of your project. This file defines how your Ruby application should be built within a Docker container.

Here's a basic Dockerfile for a Ruby on Rails project:

# Use an official Ruby runtime as a parent image
FROM ruby:latest

# Set the working directory in the container
WORKDIR /app

# Copy the Gemfile and Gemfile.lock into the container
COPY Gemfile Gemfile.lock ./

# Install any needed gems mentioned in your Gemfile
RUN bundle install

# Copy the rest of your application code into the container
COPY . .

# Expose port 3000 to the outside world
EXPOSE 3000

# Start your Rails application
CMD ["rails", "server", "-b", "0.0.0.0"]

Starting the Environment

With your environment set up, it's time to start it:

docker-compose up

Docker will keep your PostgreSQL and Redis data safe outside the containers, even if you stop or remove them.

Developing Your Application

You can start working on your Ruby on Rails project as usual. Docker will handle data safety for your PostgreSQL and Redis databases.

Shutting Down the Environment

When you're done, you can shut down the environment:

docker-compose down

Conclusion

By using Docker volumes in your development environment, you've made sure that your PostgreSQL and Redis data stays secure, even if you stop or remove containers. Docker volumes are an important part of working with containers, making sure your data is always available and protected.

With the pandemic, many software teams have transitioned to remote work, either full-time or in a hybrid model. In this article, I will focus on team communication in remote work, rather than dwelling on the pros and cons of this transition.

Remote work has led to a transformation in how teams organize and communicate, compared to the traditional office model:

• Face-to-face meetings have been replaced by online meetings.
• Communication tools like Slack, Zoom, and Google Meet have become essential.
• Documentation has gained importance in tracking work progress.

Synchronous Communication

Synchronous communication is when communication happens in real-time, and immediate responses are expected from all participants. It resembles the question-answer interaction that occurs in face-to-face communication.

Examples of synchronous communication methods used in software teams include:

• Daily Stand-Up Meetings: Short but effective meetings where teams discuss current progress, questions, or obstacles.
• Project Planning Meetings: Meetings where the team discusses the project's future and plans tasks accordingly, with everyone participating.
• Retrospective Meetings: Meetings where progress is evaluated, and the team discusses what went right or wrong in tasks or methods.
• Pair Programming: Collaborative work on a project or task by team members.
• Onboarding Meetings for New Team Members: Ensuring a smooth integration process for new team members.
• Evaluation Meetings: Meetings to assess performance.
• One-on-One Meetings: Individual meetings.
• Meetings for Sharing Important Company Updates: Meetings where significant company developments are shared.

Increasing Efficiency in Synchronous Communication

Plan Meetings in Advance:
Planning meetings a few days in advance, after checking your team members' availability, allows them to make time for it. This fosters respect among team members.

Define Meeting Objectives:
A crucial aspect of an efficient meeting is conveying its purpose and the problem to be discussed beforehand. This helps participants prepare and keeps the meeting focused.

Limit Meeting Duration:
Meetings can easily go off-topic. To prevent this, set a time limit for meetings and communicate it to participants.

Indicate Availability and Show Respect:
Synchronous communication, by nature, can disrupt the other party. To avoid this, keep your availability status up to date and show respect for others' schedules. It also helps determine if your message is genuinely urgent.

Enhance Your Working Environment:
Since the quality of internet infrastructure may not always meet expectations in remote work, take measures to avoid connection issues during team meetings. Address problems like audio quality and malfunctioning microphones.

Asynchronous Communication

Although synchronous communication may seem essential for quickly resolving urgent issues, asynchronous communication is preferred for healthy project management and employee satisfaction.

In asynchronous communication, unlike synchronous communication, real-time responses are not expected. People are given time to respond when it suits them, ensuring that no unnecessary pressure is placed on them.

Examples of asynchronous communication methods used in software teams include:

• Non-urgent questions that don't require immediate attention.
• Pull Requests
• Code Reviews and Edits
• Introducing New Team Members.
• Sharing Major Company or Project Updates.

Increasing Efficiency in Asynchronous Communication

Be Clear in Your Expectations:
Since asynchronous communication isn't instant, clarity in your message is essential. Use clear language and provide additional information or documents if necessary.

Practice Patience When Waiting for Responses:
Asynchronous communication requires patience when awaiting responses. It's crucial not to rush others and to wait for them to respond at their convenience.

Document Everything:
Don't hesitate to document planned or ongoing tasks, even if they seem trivial. These documents serve as guides for your team and future colleagues.

Summary

In situations where everything seems urgent, nothing is truly urgent. It's essential to question what's genuinely urgent and what isn't. Sending a private message to someone and then saying, "It's not urgent; can you look at it when you have time?" is counterproductive. Instead, for non-urgent matters, consider using asynchronous communication by posting in a shared group. Making this a team-wide culture contributes to a more efficient and focused team.

Best regards.