NEWS

ok1

Ich komme aus dem FHEM-Adapter- Thread mit der positiven Nachricht zurück, dass der Adapter-Maintainer @LausiD sehr kurzfristig eine Lösung geschaffen hat, das Überschreiben der Objekt-Attribute per Config-Einstellung zu unterbinden - vielen Dank auch noch mal an dieser Stelle. Die neue Adapter-Version 1.2.1 steht zur Installation und zum ausführlichen Test bereit. Bei mir hat bislang alles wie gewünscht funktioniert, die "Name"-Felder bleiben nach initialem Schreiben bei erneutem Sync unberührt.

ok1

@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:

0.2.4 ist raus.
@dslraser Ich denke, damit geht auch der CONTROL_MODE für HM-IP einschließlich BOOST. Bin man gespannt auf Eure Rückmeldung. Der Teufel steckt ja bekanntlich im Detail
VG

ja, der Teufel steckt wie immer im Detail, deshalb zwischendurch auch von mir ein herzliches Dankeschön für Deinen klasse Adapter und deine hartnäckige Arbeit und Zeit, diesen fehlerfrei zu machen ! Es funktioniert jetzt auch bei mir. Sämtliche Modi werden über den FHEM-Datenpunkt controlMode durchgeschaltet.

Zum Thema Partymodus beim Homematic-Thermostat HM-CC-RT-DN habe ich ein kleines Demo-Script geschrieben, wie über einen separaten Datenpunkt der Command-String in der Notation "PARTY_MODE_SUBMIT" zu "controlParty" umgeschrieben werden kann und damit den Party-Modus steuert. Das Script lässt sich natürlich beliebig und allgemeingültig ausbauen, z.B. um sämtliche Party-Modes aller Thermostate zu steuern, usw.

/*Umschreiben des IQontrol PARTY_MODE_SUBMIT String in Homematic controlParty String 
    PARTY_MODE_SUBMIT = "partyModeTemperature,StartTime,StartDay,StartMonth,StartYear,StopTime,StopDay,StopMonth,StopYear"
    Bsp: PARTY_MODE_SUBMIT=27,1170,15,9,19,1410,15,9,19
    controlParty Grad StartDay StartTime StopDay StopTime
    Bsp: controlParty 16 06.12.13 16:30 09.12.13 05:00
*/ 

createState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT',false);

on({id:'javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT',change:'ne'}, function (obj) {
     PartyModeSubmit2ControlParty(); 
});


function PartyModeSubmit2ControlParty () {

    var state = getState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT').val;
    var PARTY_MODE_SUBMIT = state.split(',');

    var degrees = PARTY_MODE_SUBMIT[0];
    var StartDay = PARTY_MODE_SUBMIT[2]+"."+PARTY_MODE_SUBMIT[3] + "."+ PARTY_MODE_SUBMIT[4];
    var StartTime = Math.floor(PARTY_MODE_SUBMIT[1]/60) + ":" + PARTY_MODE_SUBMIT[1] % 60;
    var StopDay = PARTY_MODE_SUBMIT[6]+"."+PARTY_MODE_SUBMIT[7] + "." + PARTY_MODE_SUBMIT[8];
    var StopTime = Math.floor(PARTY_MODE_SUBMIT[5]/60) + ":" + PARTY_MODE_SUBMIT[5] % 60; 
    
    var controlParty = degrees + " " + StartDay + " " +  StartTime + " " +  StopDay + " " +  StopTime;
    console.log("Umrechnung IQontrol Partytime: PARTY_MODE_SUBMIT= " + getState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT').val + " --> controlParty= " + controlParty); 

    setState('fhem.0.Thermostat_Studio_1_Clima.controlParty', controlParty);
}

VG,ok

ok1

@s-bormann
yepp, das war's ! Bei HomeMatic sind STATE und PCT mit dem gleichen Wert belegt. Hätte ich selbst drauf kommen müssen .... VG, ok

ok1

@LausiD
sorry für die späte Rückmeldung und herzlichen Dank für den Hinweis !
Ich habe attr ZE.Batterie alwaysTrigger 1 in fhem.cfg hinzugefügt und das Object mit den States wird nun wie von dir beschrieben angelegt:
z.B. <html>100</html>

ok1

@lausid , hättest du evtl. einen Tipp für mich ? Vielen Dank !

Hallo, ich bräuchte einen Tipp wie aus einer fhem readingsgroup Objekte in iobroker übernommen werden können.
In fhem gebe ich über eine readingsgroup die Batteriestatus sämtlicher HM-devices aus:

ok1

Hallo, ich bräuchte einen Tipp wie aus einer fhem readingsgroup Objekte in iobroker übernommen werden können.
In fhem gebe ich über eine readingsgroup die Batteriestatus sämtlicher HM-devices aus:

define ZE.Batterie readingsGroup .*:[Bb]attery\
.*:[Bb]atteryLevel
setuuid ZE.Batterie 64f24cc0-f33f-0892-fbf8-ea50595a489167af
attr ZE.Batterie alias ZE.Batterie
attr ZE.Batterie notime 1
attr ZE.Batterie room Batteriestatus
attr ZE.Batterie userReadings Battery { return (InternalVal("ZE.Batterie","valueFormat","100")
attr ZE.Batterie valueFormat {return "0" if( $VALUE eq "low" );; return "100" if( $VALUE eq "ok" );; return "25" if( $VALUE < 2.1 );; return "50" if( $VALUE < 2.3 );; return "75" if( $VALUE < 2.5 );; return "100"}
attr ZE.Batterie valueIcon {'battery.0' => 'measure_battery_0@red','battery.100' => 'measure_battery_100@green','Battery.0' => 'measure_battery_0@red','Battery.100' => 'measure_battery_100@green','batteryLevel.0' => 'measure_battery_0@red','batteryLevel.25' => 'measure_battery_25@red','batteryLevel.50' => 'measure_battery_50@orange','batteryLevel.75' => 'measure_battery_75@green','batteryLevel.100' => 'measure_battery_100@green'}

In fhem Web wird unter ZE.Batterie eine entsprechende Liste angezeigt:
Bild 435.png

Wie kann ich dieses HTML-Element oder die Werte im valueFormat als Objekt in iobroker übernehmen ? Bei einer readingsgroup ist mir das bislang noch nicht gelungen. Der Objektbaum wird im iobroker korrekt angelegt, nur das eigentliche Datenobjekt fehlt:

Bild 436.png

Danke !

ok1

gelöst - bitte löschen

ok1

Re: FHEM Adapter

@LausiD , ich erhalte seit heute Abend folgende Fehlermeldungen im Log, so dass der fhem-Adapter nicht startet.
Das System wurde nicht verändert, der aktuellste fhem-Adapter ist installiert und lief bislang einwandfrei.
(eine zweite fhem-Instanz fhem.1 startet dagegen einwandfrei ?!)

Vielen Dank schon jetzt für einen Hinweis !

fhem.0
2022-10-23 23:16:37.756	info	State value to set for "fhem.0.info.Configurations.allowedInternals" has to be type "string" but received type "boolean"

fhem.0
2022-10-23 23:16:37.750	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason

fhem.0
2022-10-23 23:16:37.748	debug	Plugin sentry destroyed

fhem.0
2022-10-23 23:16:37.746	info	terminating

fhem.0
2022-10-23 23:16:37.737	error	state.val.split is not a function

fhem.0
2022-10-23 23:16:37.736	error	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.735	error	uncaught exception: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.731	warn	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.728	warn	Exception: TypeError: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.726	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals: {"val":true,"ack":true,"ts":1666559762075,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1666547534818}

fhem.0
2022-10-23 23:16:37.717	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals (TYPE,NAME)

ok1

Re: FHEM Adapter

@LausiD , ich erhalte seit heute Abend folgende Fehlermeldungen im Log, so dass der fhem-Adapter nicht startet.
Das System wurde nicht verändert, der aktuellste fhem-Adapter ist installiert und lief bislang einwandfrei.
(eine zweite fhem-Instanz fhem.1 startet dagegen einwandfrei ?!)

Vielen Dank schon jetzt für einen Hinweis !

fhem.0
2022-10-23 23:16:37.756	info	State value to set for "fhem.0.info.Configurations.allowedInternals" has to be type "string" but received type "boolean"

fhem.0
2022-10-23 23:16:37.750	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason

fhem.0
2022-10-23 23:16:37.748	debug	Plugin sentry destroyed

fhem.0
2022-10-23 23:16:37.746	info	terminating

fhem.0
2022-10-23 23:16:37.737	error	state.val.split is not a function

fhem.0
2022-10-23 23:16:37.736	error	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.735	error	uncaught exception: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.731	warn	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.728	warn	Exception: TypeError: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.726	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals: {"val":true,"ack":true,"ts":1666559762075,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1666547534818}

fhem.0
2022-10-23 23:16:37.717	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals (TYPE,NAME)

ok1

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

Da muss mMn irgendeine weitere Komponente seine Finger im Spiel haben. Sei es ioBroker oder Admin selbst, oder ein anderer Adapter oder Skript.

"Admin" war der richtige Hinweis ! Hier wird aus dem korrekten Wert "12" im Datenpunktbaum eine "13":

Bild 276.png

Aktuelle Admin-Version v5.3.8.

ok1

@ok1 sagte in Test Adapter wireless-mbus v0.7.x:

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

EDIT 31.05.
Die Datenpunkte sind jetzt auch da:

es gibt noch einen Fehler in der Datumsangabe. Monat ist ums "1" erhöht
Bild 268.png

ok1

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

@ok1
Hi, ich habe gerade v0.8.2 auf npm veröffentlicht die den C Mode für den CUL unterstützen sollte.
Unabhängig davon ob es (hoffentlich) funktioniert oder nicht, wäre es schön wenn du mir ein Debug Log vom Start und evtl 1 oder 2 empfangenen Telegrammen zukommen lassen könntest.

vielen Dank für den schnellen Einbau des C-Modes !
Gerne das debug-Log vom Start:

wireless-mbus.1
2022-05-30 23:44:28.281	debug	connected set to true

wireless-mbus.1
2022-05-30 23:44:28.221	debug	connected set to true

wireless-mbus.1
2022-05-30 23:44:28.206	info	CUL: Receiver set to C-MODE and data reporting with RSSI

wireless-mbus.1
2022-05-30 23:44:28.204	debug	CUL: RX: 434d4f44450d0a

wireless-mbus.1
2022-05-30 23:44:28.194	debug	CUL: TX: 5832310d0a6272630d0a

wireless-mbus.1
2022-05-30 23:44:28.193	info	CUL: Version: V 1.67 CUL868

wireless-mbus.1
2022-05-30 23:44:28.190	debug	CUL: RX: 5620312e36372043554c3836380d0a

wireless-mbus.1
2022-05-30 23:44:28.173	debug	CUL: TX: 560d0a

wireless-mbus.1
2022-05-30 23:44:28.163	debug	Created device of type: CUL

wireless-mbus.1
2022-05-30 23:44:27.988	info	starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23

wireless-mbus.1
2022-05-30 23:44:18.940	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

wireless-mbus.1
2022-05-30 23:44:18.936	info	terminating

wireless-mbus.1
2022-05-30 23:44:18.928	info	Got terminate signal TERMINATE_YOURSELF

wireless-mbus.1
2022-05-30 23:42:44.129	info	List of port: [{"path":"/dev/ttyAMA0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyACM0","manufacturer":"busware.de","pnpId":"usb-busware.de_CUL868-if00","vendorId":"03eb","productId":"204b"}]

wireless-mbus.1
2022-05-30 23:42:27.170	info	CUL: Receiver set to C-MODE and data reporting with RSSI

wireless-mbus.1
2022-05-30 23:42:27.110	info	CUL: Version: V 1.67 CUL868

wireless-mbus.1
2022-05-30 23:42:26.921	info	starting. Version 0.8.2 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v12.18.4, js-controller: 4.0.23

und das erste Telegramm:

wireless-mbus.1
2022-05-30 23:48:43.943	debug	Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:48

wireless-mbus.1
2022-05-30 23:48:43.921	debug	Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18

wireless-mbus.1
2022-05-30 23:48:43.897	debug	Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30

wireless-mbus.1
2022-05-30 23:48:43.873	debug	Value QDS-29435752.data.4-17-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:48:43.846	debug	Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31

wireless-mbus.1
2022-05-30 23:48:43.822	debug	Value QDS-29435752.data.2-1-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:48:43.802	debug	Value QDS-29435752.data.1-0-VIF_HCA: 5

wireless-mbus.1
2022-05-30 23:48:43.543	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:48:43.076	debug	Creating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:48:43.072	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635311664 value calc 2022-05-30 22:48

wireless-mbus.1
2022-05-30 23:48:43.070	debug	DIB dataField 4

wireless-mbus.1
2022-05-30 23:48:43.068	debug	VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18

wireless-mbus.1
2022-05-30 23:48:43.067	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.066	debug	VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30

wireless-mbus.1
2022-05-30 23:48:43.064	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.063	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:48:43.062	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.059	debug	VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31

wireless-mbus.1
2022-05-30 23:48:43.057	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:48:43.054	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:48:43.053	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.051	debug	VIF_HCA: Value 5

wireless-mbus.1
2022-05-30 23:48:43.049	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:48:43.038	debug	Short header

wireless-mbus.1
2022-05-30 23:48:43.027	debug	3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de25803580

wireless-mbus.1
2022-05-30 23:48:43.019	debug	CUL: Message received: 3144934452574329350830a97a641800200b6e0500004b6e00000042e03e6cbf2ccb086e000000c2086cde24326c1c3ed225046d3016de258035803b

wireless-mbus.1
2022-05-30 23:48:43.014	debug	CUL: RX: 623331343439333434353235373433323933353038333041393741363431383030323030423645303530303030344236453030303030303432453033453643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333031364445323538303335383033420d0a

die beiden wichtigsten Nutzdaten "aktueller Wert HKV"

2022-05-30 23:48:43.051	debug	VIF_HCA: Value 5

und Vorjahreswert

2022-05-30 23:48:43.054	debug	VIF_HCA: Value 0

werden korrekt erkannt.

Und das 2. Telegramm:

wireless-mbus.1
2022-05-30 23:56:05.325	debug	Value QDS-29435752.data.7-0-VIF_TIME_POINT_DATE_TIME: 2022-05-30 22:55

wireless-mbus.1
2022-05-30 23:56:05.287	debug	Value QDS-29435752.data.6-0-VIF_TIME_POINT_DATE: 2022-05-18

wireless-mbus.1
2022-05-30 23:56:05.238	debug	Value QDS-29435752.data.5-17-VIF_TIME_POINT_DATE: 2022-04-30

wireless-mbus.1
2022-05-30 23:56:05.199	debug	Value QDS-29435752.data.4-17-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:56:05.163	debug	Value QDS-29435752.data.3-1-VIF_TIME_POINT_DATE: 2021-12-31

wireless-mbus.1
2022-05-30 23:56:05.129	debug	Value QDS-29435752.data.2-1-VIF_HCA: 0

wireless-mbus.1
2022-05-30 23:56:05.092	debug	Value QDS-29435752.data.1-0-VIF_HCA: 5

wireless-mbus.1
2022-05-30 23:56:05.000	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-30 23:56:04.998	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635311671 value calc 2022-05-30 22:55

wireless-mbus.1
2022-05-30 23:56:04.997	debug	DIB dataField 4

wireless-mbus.1
2022-05-30 23:56:04.996	debug	VIF_TIME_POINT_DATE: Value raw 9682 value calc 2022-05-18

wireless-mbus.1
2022-05-30 23:56:04.995	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.993	debug	VIF_TIME_POINT_DATE: Value raw 9438 value calc 2022-04-30

wireless-mbus.1
2022-05-30 23:56:04.992	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.991	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:56:04.990	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.989	debug	VIF_TIME_POINT_DATE: Value raw 11455 value calc 2021-12-31

wireless-mbus.1
2022-05-30 23:56:04.987	debug	DIB dataField 2

wireless-mbus.1
2022-05-30 23:56:04.986	debug	VIF_HCA: Value 0

wireless-mbus.1
2022-05-30 23:56:04.985	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.984	debug	VIF_HCA: Value 5

wireless-mbus.1
2022-05-30 23:56:04.982	debug	DIB dataField 11

wireless-mbus.1
2022-05-30 23:56:04.981	debug	Short header

wireless-mbus.1
2022-05-30 23:56:04.978	debug	3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a580

wireless-mbus.1
2022-05-30 23:56:04.977	debug	CUL: Message received: 3144934452574329350830a97a651800200b6e0500004b6e00000042fec66cbf2ccb086e000000c2086cde24326c1c3ed225046d3716de2521a5803b

wireless-mbus.1
2022-05-30 23:56:04.975	debug	CUL: RX: 623331343439333434353235373433323933353038333041393741363531383030323030423645303530303030344236453030303030303432464543363643424632434342303836453030303030304332303836434445323433323643314333454432323530343644333731364445323532314135383033420d0a

Eine Besonderheit der Qundis HKV ist der Versand von Zwischen-Telegrammen mit Qundis-internen Daten.
Beim FHEM Adapter hat man das über ein zusätzliches Attribut "ignoreUnknownDataBlocks" gelöst. Ist das Attribut gesetzt werden die internen Telegramme verworfen und nicht in den Datenpunkt geschrieben. In diesem kurzen Test habe ich noch kein derartiges Telegramm gefangen, lasse den Adapter weiterlaufen und füge es hier umgehend an wenn eins vorliegt.

EDIT 31.05.
Erste interne Telegramme liegen vor. Nachfolgend ein Beispiel:

wireless-mbus.1
2022-05-31 16:29:41.748	debug	Value QDS-29435752.data.2-0-VIF_TIME_POINT_DATE_TIME: 2022-05-31 15:29

wireless-mbus.1
2022-05-31 16:29:41.711	debug	Value QDS-29435752.data.1-0-VIF_TYPE_MANUFACTURER_UNKOWN: /$^,?%Rn0j

wireless-mbus.1
2022-05-31 16:29:41.673	debug	Updating device: QDS-29435752

wireless-mbus.1
2022-05-31 16:29:41.672	debug	VIF_TIME_POINT_DATE_TIME: Value raw 635375389 value calc 2022-05-31 15:29

wireless-mbus.1
2022-05-31 16:29:41.672	debug	DIB dataField 4

wireless-mbus.1
2022-05-31 16:29:41.671	debug	VIF_TYPE_MANUFACTURER_UNKOWN: Value "/\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000$^\u0000\u0000\u0000\u0000,?\u0000\u0000\u0000\u0006%Rn0\u0007\u0000\u0000\u0000\u0018j\u0002\u0000"

wireless-mbus.1
2022-05-31 16:29:41.671	debug	DIB dataField 13

wireless-mbus.1
2022-05-31 16:29:41.670	debug	Unknown manufacturer specific vif: 0x5f

wireless-mbus.1
2022-05-31 16:29:41.669	debug	No header

wireless-mbus.1
2022-05-31 16:29:41.668	debug	494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf25620780

wireless-mbus.1
2022-05-31 16:29:41.667	debug	CUL: Message received: 494493445257432935085243780dff5f350082ea1800800007b06ed2bbe12506000000bf2c00000000de240000005eb7000080008000800080008000800080009b248000000000000000002f046d1d0fdf256207803a

wireless-mbus.1
2022-05-31 16:29:41.666	debug	CUL: RX: 62343934343933343435323537343332393335303835323433373830444646354633353030383245413138303038303030303742303645443242424531323530363030303030304246324330303030303030304445323430303030303035454237303030303830303038303030383030303830303038303030383030303830303039423234383030303030303030303030303030303030324630343644314430464446323536323037383033410d0a

In welche Datenpunkte werden die Werte vom Adapter eingetragen ?
Unter wireless-mbus.1 sind sie noch nicht vorhanden:

Bild 265.png

EDIT 31.05.
Die Datenpunkte sind jetzt auch da:
Bild 267.png

ok1

@lvogt sagte in Test Adapter wireless-mbus v0.7.x:

@ok1 Gibt es denn für den CUL eine Firmware die den C Mode unterstützt?

ja, die Firmware mit Mode C Unterstützung kann man sich aus den Quellen (culfw-code-r568-trunk-culfw) einfach selbst erstellen, in dem man im Verzeichnis CUL das include "board.h" anpasst:

//ok
#define HAS_MBUS        1
#define CUL_V3  1

und nicht benötigte Module wg. geringem Speicherplatz rauskommentiert, z.B.

#if defined(CUL_V3) || defined(CUL_V4)
#  define HAS_FHT_8v                    // PROGMEM:  586b  RAM: 23b
#  define HAS_FHT_TF
#  define FHTBUF_SIZE          174      //                 RAM: 174b
#  define RCV_BUCKETS            4      //                 RAM: 25b * bucket
#  define FULL_CC1100_PA                // PROGMEM:  108b
#  define HAS_RAWSEND                   //
//#  define HAS_ASKSIN                    // PROGMEM: 1314
//#  define HAS_ASKSIN_FUP                // PROGMEM:   78
//#  define HAS_MORITZ                    // PROGMEM: 1696
#  define HAS_ESA                       // PROGMEM:  286
#  define HAS_TX3                       // PROGMEM:  168
//#  define HAS_INTERTECHNO               // PROGMEM: 1352
#  define HAS_TCM97001                  // PROGMEM:  264
#  define HAS_UNIROLL                   // PROGMEM:   92
#  define HAS_MEMFN                     // PROGMEM:  168
//#  define HAS_SOMFY_RTS                 // PROGMEM: 1716
//#  define HAS_BELFOX                    // PROGMEM:  214
#endif

Nach Flashen der Firmware konnte der CUL-Stick Qundis qcaloric 5.5 Telegramme einwandfrei lesen. Geprüft mit wmbusmeters und FHEM-CUL-Modul.

NEWS

ok1

@ok1

Best posts made by ok1

Latest posts made by ok1