End-of-Life für Non-IP-Geräte?

Kabellose und kabelgebundene Sender und Empfänger der klassischen Homematic-Serie

Moderator: Co-Administratoren

cmjay
Beiträge: 2389
Registriert: 19.09.2012, 10:53
System: CCU
Wohnort: Jottweedee
Hat sich bedankt: 251 Mal
Danksagung erhalten: 351 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von cmjay » 15.06.2022, 21:18

Ulli01 hat geschrieben:
15.06.2022, 21:02
... immerhin etwas!
... wie bei HMIP!
... leider gleich Null!
... Freude beim Jahresabschluss!
... vollkommen identisch sind!

... als auch Wired!

... zum Vorgängersystem) nicht beachten!
Psssst, ich habe günstige Satzzeichen im Angebot. 50% Preisnachlass auf Kommas und Punkte. Nur heute. :mrgreen:
Es kann leider nicht ganz ausgeschlossen werden, dass ich mich irre.
HmIP muss leider draussen bleiben. in Ausnahmefällen erlaubt
ACHTUNG! Per Portweiterleitung aus dem Internet erreichbare CCU-WebUI ist unsicher! AUCH MIT PASSWORTSCHUTZ! Daher: Portweiterleitung deaktivieren!

Benutzeravatar
Roland M.
Beiträge: 9803
Registriert: 08.12.2012, 15:53
System: CCU
Wohnort: Graz, Österreich
Hat sich bedankt: 252 Mal
Danksagung erhalten: 1379 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Roland M. » 15.06.2022, 21:49

Hallo!
Ulli01 hat geschrieben:
15.06.2022, 21:02
Es wäre völlig problemlos möglich gewesen, beide Protokolle zu integrieren,
Wenn du dir da so sicher bist, würde ich dir empfehlen, dich eQ-3 zur Verfügung zu stellen, die suchen immer gute Leute (https://karriere.eq-3.de/karriere.html)!

Mir wurde auf Usertreffen in persönlichen Gesprächen mit Entwicklern aber z.B. auch ein mir durchaus nachvollziehbarer Grund genannt, warum keine Dual-Stack-Geräte entwickelt werden können. Es ist schlicht und einfach der fehlende Speicher der Microcontroller, bzw. der fehlende Platz für zusätzliche Speicherchips.


Roland
Zuletzt geändert von Roland M. am 15.06.2022, 23:04, insgesamt 1-mal geändert.
Grund: Quoting repariert
Zur leichteren Hilfestellung bitte unbedingt beachten:
  • Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
  • Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
  • Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
  • Fehlermeldungen genau abschreiben, besser noch...
  • Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!

-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...

Xel66
Beiträge: 14163
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1499 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Xel66 » 15.06.2022, 22:01

Ulli01 hat geschrieben:
15.06.2022, 21:02
Du spekulierst jedenfalls eine Menge in der Gegend rum, immerhin etwas!
Da nehmen wir uns wohl nicht viel. Ich lehne ich mal aus dem Fenster und behaupte mal an Hand Deiner Argumentationen, dass ich zumindest technischer fundierter spekuliere (sowohl was die Elektronik als auch die Kommunikationssicherheit angeht). Zumindest versuche ich, meine Behauptungen auch technisch zu begründen. Begründungen vermisse ich in Deiner Argumentation fast vollständig.
Spekulationsbeispiele Deinerseits gefällig? :
Die Kommunikationssicherheit ist, wenn man das vernünftig anlegt, bei HM genauso groß, wie bei HMIP!
Nur weil man bei klassisch einen Systemschlüssel setzen kann, ist das noch lange nicht vergleichbar. Wäre dem so, hätten sie sich auch das alte Protokoll zertifizieren lassen und würden damit werben. Es wird einen Grund geben.
Wenn die CCU3 aber mit ins Spiel kommen muss, weil die Protokolle nicht miteinander kommunizieren, dann haben beide Systeme die gleiche Schwachstelle, was die Sicherheit angeht, und damit ist der von Dir erwünschte Effekt leider gleich Null!
Keine Ahnung, was Du damit sagen willst. Ich bezog mich ausschließlich darauf, dass das von HmIP verwendete Kommunikationsprotokoll nicht durch die Abwärtskompatibilität mit "unsicheren" Protokollen geschwächt werden soll. Dieses käme ausschließlich bei der Verwendung von Direktverknüpfungen zum Tragen. Außerdem wäre dieser Ballast in z.B. HAP-Systemen unnötig und vergrößert nur die Angriffsfläche. Genau unter dieser Bullshit-Denkweise "Abwärtskompatibilität" scheitern viele gute Ansätze zu mehr Sicherheit. Man schaue sich in der gesamten Softwarewelt um. Die CCU ist als Vermittlunsinstanz, die beide Protokolle spricht, geeignet. Dass die ganze Angelegenheit mit der Multiprotokollfähigkeit eben nicht so einfach ist, sieht man schon daran, dass auch die HAP als Rangeextender nicht in der Lage sind, das alte HM-Protokoll zu sprechen. Dieses ist nur direkt einem einzigen im System angemeldeten direkt angebundenen Funkmodul möglich. Und letztendlich steht eben ein Generationswechsel auf der Agenda. Ohne weiteres sind auch die Geräte des gleichen Herstellers nicht mit Homematic kompatibel (Du kennst FS20?). Das ist genau die gleiche Problematik.
Es wäre völlig problemlos möglich gewesen, beide Protokolle zu integrieren...
Eben nur unter Schwächung des besseren Protokolls. Verstehst Du eigentlich ansatzweise, was man Dir mitteilen will?
was sich ja auch in den zahlreichen Derivaten mit anderem Branding zeigt, bei dem die Geräte eben auch nicht unbedingt kompatibel sind, obwohl sie technisch vollkommen identisch sind!
Sowohl meine Ohren und auch meine Sprachorgane sind denen eines Chinesen bis auf genetische Unterschiede identisch. Trotzdem verstehe ich Chinesen nicht und ein Großteil der Chinesen dürfte der deutschen Sprache nicht mächtig sein. Sprich, auch auf identischer Hardware muss nicht das gleiche Firmware mit identischen Kommunikationsprotokollen laufen. In Macs stecken die gleichen Prozessoren, die auch in PCs mit Win... oder Lin... laufen. Deshalb können diese Rechner trotzdem nur über genormte Netzwerkprotokolle kommunizieren und bis vor kurzem konnte ohne zusätzliche Hilfsmittel das eine OS keine Programme des anderen ausführen.
Und die Wärme spielt beim Ausfall fehlerhafter Komponenten sicherlich eine Rolle, aber eben nur eine von vielen!
Wer blubbert sollte auch liefern. Die anderen wären? Von vom Anwender verursachten Problemen mit verschweißten Kontakten durch unsachgemäße Verwendung außerhalb der in den Datenblättern entnehmbaren Spezifikationen mal abgesehen.
Komponenten können aus dutzenden (hunderten?) Gründen ausfallen, und das betrifft eben auch die neuen Komponenten sowohl im Funkbereich, als auch Wired!
Unbestritten, aber was willst Du damit sagen? Auch Geräte anderer Hersteller fallen gelegentlich aus. So what? Die Ursache für das bekannte C26-Problem ist eindeutig thermischer Art.
Du brauchst Dir auch über die Automation in meinem Haus keine Sorgen machen...
Glaube mir, mache ich definitiv nicht. Ich helfe hier im Forum gern, mache mir aber die Probleme anderer nicht zueigen. Aber ich bin lange genug hier im Forum und auch im realen Leben unterwegs, um mir ein Bild machen zu können.

Gruß Xel66

PS:
cmjay hat geschrieben:
15.06.2022, 21:18
Psssst, ich habe günstige Satzzeichen im Angebot. 50% Preisnachlass ...
Psssst! Genaaaauuuu... :lol:
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Ulli01
Beiträge: 130
Registriert: 29.10.2012, 16:36
Hat sich bedankt: 4 Mal
Danksagung erhalten: 3 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Ulli01 » 15.06.2022, 22:44

Roland M. hat geschrieben:
15.06.2022, 21:49
Hallo!
Ulli01 hat geschrieben:
15.06.2022, 21:02
Es wäre völlig problemlos möglich gewesen, beide Protokolle zu integrieren,
Wenn du dir da so sicher bist, würde ich dir empfehlen, dich eQ-3 zur Verfügung zu stellen, die suchen immer gute Leute (https://karriere.eq-3.de/karriere.html)!

Mir wurde auf Usertreffen in persönlichen Gesprächen mit Entwicklern aber z.B. auch ein mir durchaus nachvollziehbarer Grund genannt, warum keine Dual-Stack-Geräte entwickelt werden können. Es ist schlicht und einfach der fehlende Speicher der Microcontroller, bzw. der fehlende Platz für zusätzliche Speicherchips.


Roland
Ich habe Dich bisher so eingeschätzt, dass Du auch eine gewisse Ahnung von der Technischen Seite hättest?!
Dann müsste Dir allerdings klar sein, dass es heute keine große Rolle mehr spielt, wieviel Speicher ich in einen Mikrokontroller packe, und auch ein "zusätzlicher Speicherchip", der diese wirklich technisch anspruchslose Aufgabe hätte meistern können, kann heutzutage überall untergebracht werden, wenn man das möchte!

Aber es ist natürlich einen nette Story für Leute die sich damit zufrieden geben...

Was das Jobangebot angeht, mal abgesehen davon dass ich selber eine Firma betreibe (in der übrigens ehemalige Mitarbeiter von ELV/eq-3 beschäftigt sind), würde ich niemals in einem Unternehmen arbeiten wollen, in dem eine so schlechte Arbeitsatmosphäre herrscht, wie wohl dort!
Zuletzt geändert von Roland M. am 15.06.2022, 23:02, insgesamt 1-mal geändert.
Grund: Quoting repariert
--------------------------------------------
Über 100 Geräte, u.a.:
Gelöscht wegen Problemen mit der Suchfunktion!
--------------------------------------------

Ulli01
Beiträge: 130
Registriert: 29.10.2012, 16:36
Hat sich bedankt: 4 Mal
Danksagung erhalten: 3 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Ulli01 » 15.06.2022, 22:45

cmjay hat geschrieben:
15.06.2022, 21:18
Psssst, ich habe günstige Satzzeichen im Angebot. 50% Preisnachlass auf Kommas und Punkte. Nur heute. :mrgreen:
Ja, wenn ich mir Deine anderen Beiträge so ansehe, dann verstehe ich das durchaus... :roll: :lol:
--------------------------------------------
Über 100 Geräte, u.a.:
Gelöscht wegen Problemen mit der Suchfunktion!
--------------------------------------------

Ulli01
Beiträge: 130
Registriert: 29.10.2012, 16:36
Hat sich bedankt: 4 Mal
Danksagung erhalten: 3 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Ulli01 » 15.06.2022, 22:50

Xel66 hat geschrieben:
15.06.2022, 22:01
Eben nur unter Schwächung des besseren Protokolls. Verstehst Du eigentlich ansatzweise, was man Dir mitteilen will?

Gruß Xel66
Ich verstehe dass Du zu den Leuten gehörst, die unbedingt zu allem irgend eine Meinung äussern wollen, und wenn man Ihnen dann klar macht, dass sie eben nur spekulieren, aggressiv werden!
Gibt es leider in jedem Forum, und daher beende ich diese völlig wertlose Diskussion mit Dir auch hiermit!
--------------------------------------------
Über 100 Geräte, u.a.:
Gelöscht wegen Problemen mit der Suchfunktion!
--------------------------------------------

jp112sdl
Beiträge: 12115
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2150 Mal
Kontaktdaten:

Re: End-of-Life für Non-IP-Geräte?

Beitrag von jp112sdl » 15.06.2022, 22:57

Ulli01 hat geschrieben:
15.06.2022, 21:02
Es wäre völlig problemlos möglich gewesen, beide Protokolle zu integrieren
...in die Geräte? Ist das so?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Matsch
Beiträge: 5449
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 116 Mal
Danksagung erhalten: 739 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Matsch » 15.06.2022, 23:29

jp112sdl hat geschrieben:
15.06.2022, 22:57
Ulli01 hat geschrieben:
15.06.2022, 21:02
Es wäre völlig problemlos möglich gewesen, beide Protokolle zu integrieren
...in die Geräte? Ist das so?
Glaub doch einem Fachmann mal was!

Xel66
Beiträge: 14163
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1499 Mal

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Xel66 » 16.06.2022, 02:48

Ulli01 hat geschrieben:
15.06.2022, 22:50
Ich verstehe dass Du zu den Leuten gehörst, die unbedingt zu allem irgend eine Meinung äussern wollen,
Da wir uns persönlich nicht kennen, ist mir Dein Vorurteil schrecklich egal. Ich begründe meine Standpunkte zumindest.... Da der Hersteller hierzu keine ausführlichen Angaben macht, ist man auf die wenigen publizierten Angaben und daraus folgenden hergeleiteten Hypothesen angewiesen. Und aggressiv bin ich noch lange nicht geworden. Das merkt man im geschriebenen Umfeld dann an einer robusteren Wortwahl. Aber durch Kompetenz in irgendeiner Beziehung sind Deine Beiträge und unbegründete Behauptungen auch nicht gerade aufgefallen. Auch in anderen Beziehungen ist nachweislich deutlich Luft nach oben. Mir aber egal. Du hast Dich zumindest für eine nützliche Forenfunktion qualifiziert. Ich werde Dich nicht mehr mit Antworten belästigen. Vielleicht haben ja andere Lust, sich das anzutun. *PLONK*

Gruß
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Benutzeravatar
Black
Beiträge: 5480
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 424 Mal
Danksagung erhalten: 1074 Mal
Kontaktdaten:

Re: End-of-Life für Non-IP-Geräte?

Beitrag von Black » 16.06.2022, 19:19

Die ältestes "Steuerung" an der ich beteiligt war, läuft heutzutage immer noch "beinahe" unverändert.
Es handelt sich hierbei um eine AUtomatisierung eines grösseren EInfamilienhauses grob mitte 1990er Jahre. Das System ist eine Industrie SPS S7-300, die seitdem 24/7 durchläuft. im Laufe von mittlerweile etwas mehr als 25 Jahren waren mal 2 EIngangskarten kaputt. (eine Komplett hinüber, eine tats ein EIngang nicht mehr).

Im Jahre 2020 Jahr hatten wir im Hinblick auf Verfügbarkeit-Kompatibilität die damals UR-314er (die immer noch ihren Dienst verrichtete) gegen eine aktuelle 315-PN getauscht. Grund lag aber nur darin begründet, das es
1. die damaligen Flashs nicht mehr sicher zu beziehen gibt bzw mein Uralter Simatic Flash Prommer nicht mehr an meinen Laptop unter windows 10 Funktioniert.
2. Das System an eine Middleware angebunden werden sollte. (Vertriebsaktivitäten diesbezüglich sind wie immer unnütz :mrgreen: :mrgreen: , dort läuft mittlerweile natürlich ein... richtig -- IOBroker)

die Karten gibts immer noch bei Siemens bzw bei Second Source Herstellern wie Vipa bzw Helmholz.

Wenn also ein System auf Langfristig ausgelegt sein sollte, dann redet man bei einer Immobilie mal schnell von einem Viertel Jahrhundert.
Und wenn ich nochmal eine Immobilie mit einem Wired System ausstatten müsste, dort wäre auch mit SIcherheit dann kein HmIPW verbaut, sondern auch wieder eine Industrie SPS. Siemens oder Beckhoff

Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Antworten

Zurück zu „HomeMatic Aktoren und Sensoren (klassisch)“