Hauptmenü

Neueste Beiträge

#1
Heizungssteuerung/Raumklima / Aw: Luxtronic2 mit AlphaInnote...
Letzter Beitrag von mrb - 17 November 2025, 06:30:30
Ehrlich keiner eine Idee?
#2
Sonstiges / Aw: 98_Modbus.pm Small patch f...
Letzter Beitrag von mikasabaggins - 17 November 2025, 02:39:21
Zitat von: Nestor am 29 Oktober 2025, 20:47:40Following changed in Perl 5.40:
https://perldoc.perl.org/5.40.0/perldelta#Calling-the-import-method-of-an-unknown-package-produces-a-warning

Which gives following error when starting Fhem under Perl 5.42 (latest stable):
PERL WARNING: Attempt to call undefined import method with arguments (":all") via package "SetExtensions" (Perhaps you forgot to load the package?) at ./FHEM/98_Modbus.pm line 180, <$fh> line 139.
PERL WARNING: Attempt to call undefined import method with arguments (":all") via package "TcpServerUtils" (Perhaps you forgot to load the package?) at ./FHEM/98_Modbus.pm line 185, <$fh> line 139.

Since there is no class in SetExtensions.pm or TcpServerUtils.pm, nothing can be imported, just the file included so the functions are available.

Small patch (backwards compatible):
--- -    2025-10-01 18:51:57.718221081 +0200
+++ /srv/fhem/FHEM/98_Modbus.pm    2025-09-30 18:36:53.000000000 +0200
@@ -177,12 +177,12 @@
 use strict;
 use warnings;
 use GPUtils        qw(:all);
-use SetExtensions  qw(:all);
+use SetExtensions;
 use Time::HiRes    qw(gettimeofday tv_interval sleep);    # work with floats, not just full seconds
 use POSIX          qw(strftime);
 use Encode          qw(decode encode);
 use Scalar::Util    qw(looks_like_number);
-use TcpServerUtils  qw(:all);
+use TcpServerUtils;
 use DevIo;
 use FHEM::HTTPMOD::Utils qw(:all);
 use Scalar::Util qw(weaken);                # needed for backlinks in queue structures (see chapter 11 in PBP / memory leak reported with relays)
Retro Bowl
Is it completely safe to remove qw(:all) from use SetExtensions and use TcpServerUtils in 98_Modbus.pm, or could this cause issues in setups with more complex Modbus configurations?
#3
FHEM Code changes / Revision 30535: 76_SolarForeca...
Letzter Beitrag von System - 16 November 2025, 23:21:09
Revision 30535: 76_SolarForecast: Version 1.60.5

76_SolarForecast: Version 1.60.5

Source: Revision 30535: 76_SolarForecast: Version 1.60.5
#4
English Corner / Aw: REST API Integration Patte...
Letzter Beitrag von Doriiaan - 16 November 2025, 23:17:21
Thanks, here's a concrete example to make the flow clearer.
Pi Zero receives a raw temperature reading → normalizes it → publishes to MQTT → FHEM picks it up and triggers a POST to the FastAPI endpoint to persist the updated state. In parallel, some ESPHome nodes may hit the same endpoint directly when the preprocessing layer is unavailable.

What I'm evaluating now is whether a rotating HMAC per node (salted at deploy time) gives better isolation than a static bearer token, especially during situations where FHEM rebuilds its event queue or when the Zero drops out and traffic patterns shift. The goal is to keep the API stateless but still differentiate automation-triggered updates from user-initiated calls without overengineering the whole thing.
#5
EnOcean / Aw: FL62 Verschlüsselt anlerne...
Letzter Beitrag von Flachzange - 16 November 2025, 23:10:09
Zitat von: Damu am 16 November 2025, 22:53:07https://forum.fhem.de/index.php?topic=108472.15

Zuerst ging der FL62 nur verschlüsselt.

Dort wird der FL62 aber nicht mit 4BS und A5-38-08 angesteuert, sondern FHEM verhält sich wie ein Taster und von dem wissen wir ja, dass er funktioniert. Das ist die Variante, die man bisher auch bei FSR61 und Co nutzen musste. Mein FSR61 für das Garagentor läuft seit Jahren so verschlüsselt.
#6
Anfängerfragen / Aw: Systembefehl echo
Letzter Beitrag von horni - 16 November 2025, 23:07:01
Ja super. Besten Dank.. Da wäre ich Anfänger ja nie drauf gekommen. Funktioniert dann gleich ohne Probleme.
#7
Anfängerfragen / Aw: Systembefehl echo
Letzter Beitrag von TomLee - 16 November 2025, 22:55:22
Hallo,

ohne es jetzt nachvollzogen zu haben, würde ich vermuten das in qq() die Variablen aufgelöst werden.

system(qq(echo "outsidewert = $wgt1 \noutfeuchtewert = $wgt2 "> /tmp/technolineouttemp.txt))}
Gruß Thomas

edit:

ausprobiert, sollte funzen.
#8
English Corner / Aw: REST API Integration Patte...
Letzter Beitrag von passibe - 16 November 2025, 22:54:40
Hi,

I am a bit confused as to how exactly the data flows in your setup and which service is running on which device/which device needs to access which other device (or service/endpoint).

Could you maybe provide a step-by-step example on
  • how the endpoint you are trying to secure is interacted with, and,
  • afterwards, what data flows to which point?
Don't make this theoretical, just take something your endpoint is actually used for (e.g. receiving temperature readings from some sensor).



Also, as you already seem to have noticed, this doesn't really relate to FHEM, but rather (only) to the Python microservice (feel free to correct me if I got this wrong).

So basically you can do whatever you want, as long as the devices using the endpoint are able to handle the auth implementation you choose. Tbh I wouldn't necessarily overcomplicate this and just use something already available within the microservice's stack that is also supported by your clients.
#9
EnOcean / Aw: FL62 Verschlüsselt anlerne...
Letzter Beitrag von Damu - 16 November 2025, 22:53:07
https://forum.fhem.de/index.php?topic=108472.15

Zuerst ging der FL62 nur verschlüsselt.
#10
English Corner / REST API Integration Patterns ...
Letzter Beitrag von Doriiaan - 16 November 2025, 22:39:57
Hi everyone,

I'm currently redesigning part of my home automation stack and I'm running into an architectural question related to REST API design, authentication boundaries, and distributed message flows between FHEM nodes.

Setup looks like this:

  • Main FHEM instance running on a Raspberry Pi 5 (Debian Bookworm, Perl 5.36)
  • Secondary automation layer on a Pi Zero W doing lightweight event preprocessing
  • A custom REST API endpoint exposed via a Python microservice (uvicorn / FastAPI)
  • MQTT bridging between both Pis, with FHEM subscribing to upstream processed topics
  • Some devices running ESPHome publishing events directly into the same namespace

The part I'm unsure about is the best practice for securing the API endpoint when the request origin may vary (local LAN, remote workflow triggers, or internal FHEM modules).

I've been reading about different authentication strategies (header-based tokens, asymmetric signatures, short-lived session keys, pre-shared HMAC tokens injected at the edge), and I'm trying to understand what makes most sense when:

  • FHEM acts as both consumer and event generator
  • The API needs to differentiate automation-triggered calls from user-triggered calls
  • The traffic is mostly local but should still follow proper isolation rules
  • A fallback mechanism is needed when the preprocessing Pi becomes unreachable
  • The workflow must remain consistent even if FHEM rebuilds the event queue

I found a technical explanation of REST fundamentals that helped clarify the stateless flow and the way headers should be structured for modular systems:
https://networklessons.com/cisco/ccna-200-301/introduction-to-rest-api
https://networklessons.com/network-automation/rest-api-authentication
https://pingmynetwork.com/network/ccna-200-301/rest-api
https://en.wikipedia.org/wiki/REST

Before I over-engineer the whole thing, I'd like to know what other FHEM users do when they expose REST endpoints beside the core FHEM modules.

Thanks in advance
Dorian