Seitdem ich letzte Woche den Parameter "CC1352P and CC26X2R1 Sendeleistung" auf "high+" gestellt habe, ist die Verbindung nie mehr abgebrochen.
Eventuell hilft das bei anderen mit Verbindungsproblemen auch.
Seitdem ich letzte Woche den Parameter "CC1352P and CC26X2R1 Sendeleistung" auf "high+" gestellt habe, ist die Verbindung nie mehr abgebrochen.
Eventuell hilft das bei anderen mit Verbindungsproblemen auch.
Ich hatte damals auch noch ein Script für mich geschrieben, welches diverse Werte ausrechnet die in den ausgelesenen Daten nicht vorhanden sind. Bzw. bildet es auch die Werte in leichter verständlichen Objektnamen ab, denn die OBIS Codes sind ja nicht besonders gut zu merken.
Vielleicht kann es ja jemand brauchen.
Edit 1:
DrwPower
wird aktuell noch nicht berechnet und DlvPower
müsste nur bei negativen Werten übernommen werden.
const CtFactor = 200 // factor for current transformers
const VtFactor = 1 // factor for voltage transformers
const path = '0_userdata.0.EMTR1'
// create required objects on startup
createState(path + '.info.MeterOwnerNumber')
createState(path + '.info.Firmware')
createState(path + '.info.Error')
createState(path + '.Voltage', {type: "number", unit: 'V'})
createState(path + '.VoltageL1', {type: "number", unit: 'V'})
createState(path + '.VoltageL2', {type: "number", unit: 'V'})
createState(path + '.VoltageL3', {type: "number", unit: 'V'})
createState(path + '.Current', {type: "number", unit: 'A'})
createState(path + '.CurrentL1', {type: "number", unit: 'A'})
createState(path + '.CurrentL2', {type: "number", unit: 'A'})
createState(path + '.CurrentL3', {type: "number", unit: 'A'})
createState(path + '.Frequency', {type: "number", unit: 'Hz'})
createState(path + '.cosPhi', {type: "number"})
createState(path + '.sinPhi', {type: "number"})
// DLV = delivery to grid
createState(path + '.DLV1.Power', {type: "number", unit: 'kW'})
createState(path + '.DLV1.Energy', {type: "number", unit: 'kWh'})
createState(path + '.DLV1.ReactiveEnergy', {type: "number", unit: 'kVarh'})
createState(path + '.DLV1.ReactivePower', {type: "number", unit: 'kVar'})
// DRW = draw from grid
createState(path + '.DRW1.Power', {type: "number", unit: 'kW'})
createState(path + '.DRW1.Energy', {type: "number", unit: 'kWh'})
createState(path + '.DRW1.ReactiveEnergy', {type: "number", unit: 'kVarh'})
createState(path + '.DRW1.ReactivePower', {type: "number", unit: 'kVar'})
var MeterOwnerNumber
var Firmware
var Error
var CurrentTime
var CurrentDate
var Frequency
var CurrentL1 // = 3.43 A
var CurrentL2 // = 3.35 A
var CurrentL3 // = 3.36 A
var CurrentN // = 0.04 A
var Current // = calulated
var VoltageL1 // = 241.1 V
var VoltageL2 // = 241.1 V
var VoltageL3 // = 241.1 V
var Voltage // = calulated
var Angle_U_L1_to_U_L1 // = 0*Deg
var Angle_U_L2_to_U_L1 // = 120*Deg
var Angle_U_L3_to_U_L1 // = 240*Deg
var Angle_I_L1_to_U_L1 // = 200*Deg
var Angle_I_L2_to_U_L1 // = 321*Deg
var Angle_I_L2_to_U_L2 // = calulated
var Angle_I_L3_to_U_L1 // = 80*Deg
var Angle_I_L3_to_U_L3 // = calulated
var Angle
var CosPhi // = calulated
var SinPhi // = calulated
var DlvEnergy = 0.0
var DlvReactiveEnergy = 0.0
var DlvPower = 0.0
var DlvReactivePower = 0.0
var DrwEnergy = 0.0
var DrwReactiveEnergy = 0.0
var DrwPower = 0.0
var DrwReactivePower = 0.0
on({ id: 'smartmeter.0.1-0:2_8_0.value', change: 'any' }, function (data) {
// wait 1000 ms when this datapoint changed to make sure all datapoints got updated
setTimeout(() => {
MeterOwnerNumber = getState('smartmeter.0.1-0:0_0_0.value').val;
Firmware = getState('smartmeter.0.1-0:0_2_0.value').val;
Error = getState('smartmeter.0.1-0:97_97.value').val;
DrwEnergy = getState('smartmeter.0.1-0:1_8_0.value').val;
DrwReactiveEnergy = getState('smartmeter.0.1-0:3_8_0.value').val;
DlvEnergy = getState('smartmeter.0.1-0:2_8_0.value').val;
DlvReactiveEnergy = getState('smartmeter.0.1-0:4_8_0.value').val;
CurrentL1 = getState('smartmeter.0.1-0:31_7.value').val * CtFactor;
CurrentL2 = getState('smartmeter.0.1-0:51_7.value').val * CtFactor;
CurrentL3 = getState('smartmeter.0.1-0:71_7.value').val * CtFactor;
CurrentN = getState('smartmeter.0.1-0:91_7.value').val * CtFactor;
VoltageL1 = getState('smartmeter.0.1-0:32_7.value').val * VtFactor;
VoltageL2 = getState('smartmeter.0.1-0:52_7.value').val * VtFactor;
VoltageL3 = getState('smartmeter.0.1-0:72_7.value').val * VtFactor;
Frequency = getState('smartmeter.0.1-0:14_7.value').val * VtFactor;
Angle_U_L1_to_U_L1 = getState('smartmeter.0.1-0:81_7_0.value').val;
Angle_U_L2_to_U_L1 = getState('smartmeter.0.1-0:81_7_1.value').val;
Angle_U_L3_to_U_L1 = getState('smartmeter.0.1-0:81_7_2.value').val;
Angle_I_L1_to_U_L1 = getState('smartmeter.0.1-0:81_7_4.value').val;
Angle_I_L2_to_U_L1 = getState('smartmeter.0.1-0:81_7_5.value').val;
Angle_I_L3_to_U_L1 = getState('smartmeter.0.1-0:81_7_6.value').val;
Current = (CurrentL1 + CurrentL2 + CurrentL3) / 3;
Voltage = ((VoltageL1 + VoltageL2 + VoltageL3) / 3) * Math.sqrt(3);
Angle_I_L2_to_U_L2 = Angle_I_L2_to_U_L1 - 120;
Angle_I_L3_to_U_L3 = Angle_I_L3_to_U_L1 + 120;
Angle = (((Angle_I_L1_to_U_L1 + Angle_I_L2_to_U_L2 + Angle_I_L3_to_U_L3) / 3) - 180);
CosPhi = Math.cos(Angle * (Math.PI / 180));
SinPhi = Math.sin(Angle * (Math.PI / 180));
DlvPower = Voltage * Current * CosPhi * Math.sqrt(3) / 1000;
DlvReactivePower = Voltage * Current * SinPhi * Math.sqrt(3) / 1000;
setState(path + '.info.MeterOwnerNumber', MeterOwnerNumber)
setState(path + '.info.Firmware', Firmware)
setState(path + '.info.Error', Error)
setState(path + '.Current', Math.round(Current*10)/10);
setState(path + '.CurrentL1', CurrentL1);
setState(path + '.CurrentL2', CurrentL2);
setState(path + '.CurrentL3', CurrentL3);
setState(path + '.Voltage', Math.round(Voltage*100)/100);
setState(path + '.VoltageL1', VoltageL1);
setState(path + '.VoltageL2', VoltageL2);
setState(path + '.VoltageL3', VoltageL3);
setState(path + '.Frequency', Frequency);
setState(path + '.cosPhi', CosPhi);
setState(path + '.sinPhi', SinPhi);
setState(path + '.DRW1.Energy', DrwEnergy);
setState(path + '.DRW1.Power', Math.round(DrwPower*10)/10);
setState(path + '.DRW1.ReactiveEnergy', DrwReactiveEnergy);
setState(path + '.DRW1.ReactivePower', Math.round(DrwReactivePower*10)/10);
setState(path + '.DLV1.Energy', DlvEnergy);
setState(path + '.DLV1.Power', Math.round (DlvPower * 10)/10);
setState(path + '.DLV1.ReactiveEnergy', DlvReactiveEnergy);
setState(path + '.DLV1.ReactivePower', Math.round(DlvReactivePower*10)/10);
}, 1000);
});
Das sieht dann im Ergebnis so aus:
Das hier waren meine finalen Einstellungen mit welchen es dann schlussendlich funktioniert hat.
@marcush said in Verbrauchsanzeige mit VIS und Grafana:
Also tatsächlich von 00:00 bis 24:00.
Mit diesen Einstellungen sollte es klappen, ich hatte auch etwas länger suchen und versuchen müssen bis es funktionierte:
@marcush said in Verbrauchsanzeige mit VIS und Grafana:
Stromverbrauch Rest des Hauses (ges. - Heizung)
Geht das mit Grafana eigenen Mitteln, oder muss ich dazu den Wert in ioBroker bilden und separat aufzeichnen?
Das habe ich so gelöst:
Nicht benötigte Anzeigen für die Zwischenberechnung werden dann einfach ausgeblendet:
Dies sieht dann bei mir etwa so aus:
Gibt es hier eigentlich Neuigkeiten zu den Update-Möglichkeiten der Aqara Sensoren?
Ich habe hier mehrere Aqara Temperatur-Sensoren welche sich seltsam verhalten.
Die Batterie-Kapazität im Wohnzimmer etwa ist von einem Moment auf den anderen von 95% auf 30% gefallen.
Ebenso beim Sensor in der Küche und im Badezimmer, das hier war ein Screenshot 30 Minuten davor:
Der Verlauf im Wohnzimmer:
Die Verbindung zum Sensor im Schlafzimmer ging mitten im Betrieb verloren und scheint auch nicht mehr von alleine wieder zu kommen, obwohl ich den Sensor jetzt auch im selben Raum habe wie den SONOFF Zigbee 3.0 USB Dongle Plus,TI CC2652P + CP2102(N).
(der kleine Spitz nach oben bei der Quality am Ende dürfte vom Update des Zigbee Adapters von 1.7.5 auf 1.7.6 kommen)
Der Kühlschrank liefert seit gestern Abend auch keine neuen Werte mehr. Die Link-Qualität viel sukzessive ab, eine Verbindung scheint aber noch zu bestehen.
Jetzt war es eben meine Überlegung ob es ein Software Update gibt, welches hier vielleicht Abhilfe schaffen könnte.
Gibt es einen Grund warum ihr Zigbee2MQTT verwendet und nicht direkt die Zigbee Integration im ioBroker?
Könnte das auch einen Einfluss darauf haben ob sich Geräte direkt am Coordinator oder an einem Router anmelden (ich vermute mal eher nicht)?
Nachdem heute wieder Probleme aufgetreten sind und auch ein neu-Koppeln nicht mehr möglich war, habe ich den Sonoff USB Stick mit einem USB Verlängerungskabel vom mini-PC etwa 1m entfernt und auf einmal klappte die Kommunikation bzw. das pairing wieder.
k.A. warum dies nun geholfen hat, bei einigen anderen half es auch soweit ich gelesen habe.
Es half bei mir die Firmware 20230507 (von zuvor 20220219), wie unter folgendem Link beschrieben, auf meinen Sonoff Zigbee USB Dongle (ZBDongle-P) zu installieren.
Danach klappte das Pairing auch wieder.
k.A. warum das auf einmal notwendig war, da zuvor ja schon alles einige Zeit lief.
https://haus-automatisierung.com/hardware/sonoff/2022/01/11/sonoff-zigbee-usb-dongle-plus.html
Systemdata | Bitte Ausfüllen |
---|---|
Hardwaresystem: | NUC/via Docker in Proxmox Linux Container |
Arbeitsspeicher: | 4 GB |
Festplattenart: | SSD-Karte |
Betriebssystem: | Debian / Docker |
Ich habe vor etwa einem Jahr einen Sonoff USB Zigbee Stick installiert und einige Geräte gepairt.
Danach hatte ich immer wieder Probleme mit Aquara Geräten, dass ich diese die Verbindung verloren und ich diese neu pairen musste.
Zwischendurch habe ich auch immer wieder Adapter Updates oder auch Iobroker updates über den Docker Container gemacht.
Vor ein paar Wochen ist mir dann augefallen, dass 2-3 Bewegungsmelder nicht mehr funktionierten und diese im Zigbee nicht mehr aktualisiert wurden.
Danach habe ich drei (verschiedene Hersteller) Bewegungsmelder versucht neu zu pairen (Reset Taster beim Gerät für 5s gedrückt gehalten, Blinken zeigt auch aktives Pairing an), aber dies funktioniert ohne einen mir erkennbaren Fehler einfach nicht. Der Counter zählt die Zeit herunter und dazwischen gibt es keine weiteren Meldungen.
Das hier ist das Log File von einem Neustart des Adapters bis hin zum Ende des Pairing-Versuchs.
2023-12-20 22:14:38.988 - info: zigbee.0 (1383248) Got terminate signal TERMINATE_YOURSELF
2023-12-20 22:14:38.999 - info: host.iob0 stopInstance system.adapter.zigbee.0 send kill signal
2023-12-20 22:14:38.990 - info: zigbee.0 (1383248) cleaned everything up...
2023-12-20 22:14:39.047 - info: zigbee.0 (1383248) Zigbee: disabling joining new devices.
2023-12-20 22:14:39.490 - info: zigbee.0 (1383248) terminating
2023-12-20 22:14:39.491 - info: zigbee.0 (1383248) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2023-12-20 22:14:40.003 - info: host.iob0 stopInstance system.adapter.zigbee.0 killing pid 1383248
2023-12-20 22:14:40.043 - info: host.iob0 instance system.adapter.zigbee.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2023-12-20 22:14:42.056 - info: host.iob0 instance system.adapter.zigbee.0 started with pid 1384076
2023-12-20 22:14:45.013 - info: zigbee.0 (1384076) starting. Version 1.8.25 in /opt/iobroker/node_modules/iobroker.zigbee, node: v18.18.2, js-controller: 5.0.17
2023-12-20 22:14:45.099 - info: zigbee.0 (1384076) delete old Backup files. keep only last 10
2023-12-20 22:14:45.100 - info: zigbee.0 (1384076) Starting Zigbee npm ...
2023-12-20 22:14:45.310 - info: zigbee.0 (1384076) Installed Version: iobroker.zigbee@1.8.25
2023-12-20 22:14:46.209 - info: zigbee.0 (1384076) Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20220219}}
2023-12-20 22:14:46.215 - info: zigbee.0 (1384076) Unable to disable LED, unsupported function.
2023-12-20 22:14:46.226 - info: zigbee.0 (1384076) --> transmitPower : high+
2023-12-20 22:14:46.242 - info: zigbee.0 (1384076) Currently 21 devices are joined:
2023-12-20 22:14:46.323 - info: zigbee.0 (1384076) 0x00158d0008385c04 (addr 60892): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2023-12-20 22:14:46.326 - info: zigbee.0 (1384076) 0x00158d00083686ac (addr 58280): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
2023-12-20 22:14:46.327 - info: zigbee.0 (1384076) 0x00158d0008a6cd26 (addr 64146): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2023-12-20 22:14:46.328 - info: zigbee.0 (1384076) 0x00158d0008a6c595 (addr 50923): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2023-12-20 22:14:46.328 - info: zigbee.0 (1384076) 0x00158d0008913f4b (addr 49526): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2023-12-20 22:14:46.329 - info: zigbee.0 (1384076) 0x00158d00088fc7e6 (addr 63812): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2023-12-20 22:14:46.330 - info: zigbee.0 (1384076) 0x943469fffe4b3165 (addr 33198): LED2003G10 - IKEA TRADFRI LED bulb E26/27 1100/1055/1160 lumen, dimmable, white spectrum, opal white (Router)
2023-12-20 22:14:46.331 - info: zigbee.0 (1384076) 0x000b57fffe96ffde (addr 20961): E1525/E1745 - IKEA TRADFRI motion sensor (EndDevice)
2023-12-20 22:14:46.332 - info: zigbee.0 (1384076) 0x84ba20fffead873e (addr 24814): LED2003G10 - IKEA TRADFRI LED bulb E26/27 1100/1055/1160 lumen, dimmable, white spectrum, opal white (Router)
2023-12-20 22:14:46.333 - info: zigbee.0 (1384076) 0x00124b0029170057 (addr 3477): SNZB-03 - SONOFF Motion sensor (EndDevice)
2023-12-20 22:14:46.334 - info: zigbee.0 (1384076) 0xa4c138d4d312e382 (addr 21256): IH-K009 - TuYa Temperature & humidity sensor (EndDevice)
2023-12-20 22:14:46.335 - info: zigbee.0 (1384076) 0x00124b0014ca1431 (addr 3877): GL-C-008-1ID - Gledopto Zigbee LED Controller RGB+CCT (1 ID) (Router)
2023-12-20 22:14:46.335 - info: zigbee.0 (1384076) 0xb4e3f9fffefd8fb5 (addr 30583): E1746 - IKEA TRADFRI signal repeater (Router)
2023-12-20 22:14:46.336 - info: zigbee.0 (1384076) 0xa4c138c9a827d319 (addr 18954): IH-K009 - TuYa Temperature & humidity sensor (EndDevice)
2023-12-20 22:14:46.337 - info: zigbee.0 (1384076) 0x94deb8fffe3c3d5e (addr 45468): TS0601_thermostat - TuYa Radiator valve with thermostat (EndDevice)
2023-12-20 22:14:46.338 - info: zigbee.0 (1384076) 0xa4c13842eb171234 (addr 33004): IH012-RT01 - TuYa Motion sensor (EndDevice)
2023-12-20 22:14:46.339 - info: zigbee.0 (1384076) 0xf4b3b1fffec3ff25 (addr 9193): LED2003G10 - IKEA TRADFRI LED bulb E26/27 1100/1055/1160 lumen, dimmable, white spectrum, opal white (Router)
2023-12-20 22:14:46.339 - info: zigbee.0 (1384076) 0x90fd9ffffe1958d6 (addr 10318): E1524/E1810 - IKEA TRADFRI remote control (EndDevice)
2023-12-20 22:14:46.340 - info: zigbee.0 (1384076) 0xa4c138ee4301f9c4 (addr 23626): IH-K009 - TuYa Temperature & humidity sensor (EndDevice)
2023-12-20 22:14:46.341 - info: zigbee.0 (1384076) 0x54ef4410006be244 (addr 39156): RTCGQ14LM - Xiaomi Aqara P1 human body movement and illuminance sensor (EndDevice)
2023-12-20 22:14:46.344 - info: zigbee.0 (1384076) 0x00124b0029294115 (addr 39345): SNZB-04 - SONOFF Contact sensor (EndDevice)
2023-12-20 22:14:46.345 - info: zigbee.0 (1384076) Zigbee started
2023-12-20 22:14:46.426 - info: zigbee.0 (1384076) debug devices set to []
2023-12-20 22:14:47.657 - warn: zigbee.0 (1384076) DeviceAvailability:Failed to ping 0xb4e3f9fffefd8fb5 TRADFRI Signal Repeater
2023-12-20 22:14:58.124 - info: admin.0 (167) ==> Connected system.user.admin from ::ffff:192.168.90.220
2023-12-20 22:14:58.658 - info: zigbee.0 (1384076) List of port: [{"path":"/dev/ttyUSB0"},{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS10"},{"path":"/dev/ttyS11"},{"path":"/dev/ttyS12"},{"path":"/dev/ttyS13"},{"path":"/dev/ttyS14"},{"path":"/dev/ttyS15"},{"path":"/dev/ttyS16"},{"path":"/dev/ttyS17"},{"path":"/dev/ttyS18"},{"path":"/dev/ttyS19"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS20"},{"path":"/dev/ttyS21"},{"path":"/dev/ttyS22"},{"path":"/dev/ttyS23"},{"path":"/dev/ttyS24"},{"path":"/dev/ttyS25"},{"path":"/dev/ttyS26"},{"path":"/dev/ttyS27"},{"path":"/dev/ttyS28"},{"path":"/dev/ttyS29"},{"path":"/dev/ttyS3"},{"path":"/dev/ttyS30"},{"path":"/dev/ttyS31"},{"path":"/dev/ttyS4"},{"path":"/dev/ttyS5"},{"path":"/dev/ttyS6"},{"path":"/dev/ttyS7"},{"path":"/dev/ttyS8"},{"path":"/dev/ttyS9"}]
2023-12-20 22:15:00.177 - info: zigbee.0 (1384076) Zigbee: allowing new devices to join.
2023-12-20 22:15:09.591 - warn: zigbee.0 (1384076) DeviceAvailability:Failed to ping 0x84ba20fffead873e TRADFRIbulbE27WSglobeopal1055lm
2023-12-20 22:15:09.605 - warn: zigbee.0 (1384076) DeviceAvailability:Failed to ping 0x00124b0014ca1431 GLEDOPTO
2023-12-20 22:15:10.329 - warn: zigbee.0 (1384076) DeviceAvailability:Failed to ping 0xf4b3b1fffec3ff25 TRADFRIbulbE27WSglobeopal1055lm
2023-12-20 22:15:19.664 - warn: zigbee.0 (1384076) DeviceAvailability:Failed to ping 0x943469fffe4b3165 TRADFRIbulbE27WSglobeopal1055lm
2023-12-20 22:15:30.891 - info: admin.0 (167) ==> Connected system.user.admin from ::ffff:192.168.90.220
2023-12-20 22:16:01.439 - info: zigbee.0 (1384076) Zigbee: stop joining
Andere Geräte welche via Zigbee angebunden sind funktionieren noch, es kann also kein grundsätzliches Kommunikationsproblem mit dem Zigbee Stick oder dem Zigbee System sein.
Woran könnte es sonst noch liegen, dass keine neuen Geräte mehr gepairt werden können?
@meister-mopper sagte in Alpha Testing: OCPP Wallbox Adapter:
Nach meinem Verständnis solltest Du für jede Wallbox eine eigene Instanz mit jeweils verschiedenen (unbenutzten) ports verwenden.
Auf diesem Screenshot hier ist zu sehen, dass pro Adapter Namen in den Objekten vergeben werden.
Demnach würden auch in einer Instanz mehrere WB angezeigt werden können.
https://forum.iobroker.net/assets/uploads/files/1670836539232-objektscreenshot-2022-12-12-101452.jpg
Ich glaube daher eher nicht, dass es die Idee dahinter ist pro WB eine Instanz anzulegen.
Wird dieser Name von der WB mit übermittelt?
Falls ja, dann ist dies bei manchen WB vielleicht nicht der Fall. Hier könnte dann der Adapter Namen oder Nummern vergeben, vl. etwa die IP Adresse vom Adapter, welche man vermutlich über die Verbindung mitbekommt.
Ich habe zwei Fronius Wattpilot Wallboxen, doch aus irgend einem Grund scheint hier kein Name im Objekt auf.
Bei einem Gerät wäre das vielleicht noch kein Problem, aber bei mehreren Geräten schreiben dann alle auf dieselben Objekte.
Sollten hier bei meterValues nicht auch Daten drinnen stehen?
ocpp.0
2023-06-08 11:30:12.023 info Sending GetConfiguration to "/"
ocpp.0
2023-06-08 11:30:10.906 info Requesting MeterValues from "/"
ocpp.0
2023-06-08 11:30:09.952 info Received Status Notification from "/": Available
ocpp.0
2023-06-08 11:30:09.899 info Received Status Notification from "/": Available
ocpp.0
2023-06-08 11:30:09.806 info Received boot notification from "/"
ocpp.0
2023-06-08 11:30:09.782 info Requesting StatusNotification from "/"
ocpp.0
2023-06-08 11:30:09.781 info New device connected: "/"
ocpp.0
2023-06-08 11:30:09.643 info New valid connection from "/" (http/ocpp1.6)
ocpp.0
2023-06-08 11:29:53.216 info Server listening on port 9220
ocpp.0
2023-06-08 11:29:53.201 info Starting OCPP Server
ocpp.0
2023-06-08 11:29:53.184 info starting. Version 0.4.0 in /opt/iobroker/node_modules/iobroker.ocpp, node: v18.16.0, js-controller: 4.0.24
Einzelne Namen (ST01/ST02) wurden in der App vergeben, als Url wurde ws://192.168.13.2:8220 eingetragen.
Woran könnte das liegen?
Ich würde ich gerne eine Überschussladung realisieren, habe aber Huawei Wechselrichter welche nicht direkt mit den Fronius WB zusammenarbeiten.
Wäre dies über IOB und OCPP möglich? Könnte die WB dies dann bei Bedarf (z.B. Next-Trip-Mode, wo Auto bis Zeit x zu y% geladen sein soll) auch übersteuern?
Ich habe dasselbe Problem.
Mir ist nicht klar wie ich einen Benutzer anlegen kann, welcher nur auf die VIS Runtime Zugriff hat, nicht aber auf das ioBroker System selbst oder auf den Vis Editor.
@schwarms
Bitte um einen Link zu dem Issue welches du auf Github angelegt hast.
@robert-ke
Ja das ist korrekt, die 50 hatte ich schon auf dein Wandlerverhältnis adaptiert.
Ich habe einen TuYa TS0601 TRV bei mir laufen, er lies sich zwar problemlos über den Sonoff Zigbee USB Stick einbinden, allerdings sind mir bisher zwei Probleme aufgefallen.
Er findet seinen korrekten 0-Punkt nicht mehr.
Am Anfang macht er eine Kalibierung und fährt dann einmal ganz zu bis der Motor merklich auf Widerstand trifft (vermutlich Abschaltung nach Strom) und er findet so seinen 0% Punkt.
Doch danach wenn er anfängt auf und ab zu regeln und wieder bei 0% landet, dann ist das Heizkörperventil nicht ganz zu und der Heizkörper wird immer noch mit Warmwasser durchströmt.
Erst wenn man ihm dann das Zigbee Kommando über { "force": "close" } via send_payload
schickt und fährt er wieder auf seinen echten 0-Punkt und schließt das HK-Ventil ganz.
Als zweites zeigt er auch noch ein seltsames Verhalten in der Regelung.
Bei Abwesenheit schalte ich über den ioBroker auf den eco-Mode um, wodurch der Sollwert von 21 °C auf 17 °C reduziert wird. Sobald ich dann nach Hause komme, wird er wieder auf den comfort-Mode umgeschaltet (21 °C). Dann fährt er das Ventil plötzlich von 0% auf 40% auf, und das obwohl der Sollwert (target) schon genau erreicht ist, es ist also nicht zu kalt.
Dadurch wird der Raum natürlich unnötig aufgeheizt und erst wenn der Sollwert überschritten wird, dann schließt das Ventil wieder langsam bis es auf 0 steht und dann eben wg. dem ersten Problem doch nicht ganz geschlossen ist.
Warum der Zähler über deine Eingaben am Terminal nicht antwortet verstehe ich eigentlich nicht, hier könntest du evtl. noch ein anderes Terminal ausprobieren, es sieht für mich aber auch in Log Daten so aus, als ob die Werte für Strom und Spannung usw. vom Zähler einfach nicht übertragen werden.
Solche Logs hier am besten als Text und nicht als Screenshot posten, dann wird nichts abgeschnitten und man kann auch im Text suchen bzw. diesen ggf. weiterverarbeiten.
Ein anderer Ansatz wäre es auch noch, wenn man aus zwei Auslesungen der kWh Werte eine Differenz bildet und über die Zeitmessung zwischen den Auslesungen dann auf die Leistung zurück rechnet. Wenn dir 2-3 Minuten Aktualisierungen reichen, dann solltest du damit auf brauchbare Werte kommen.
Ich hatte das damals auch gemacht und habe hier noch ein Code-Schnipsel dafür gefunden mit welchem ich getestet hatte.
on({ id: 'smartmeter.0.1-0:1_8_0.value', change: 'any' }, function (data) {
DrwPower = (((data.state.val - data.oldState.val) * (3600000 / ((data.state.ts - data.oldState.ts)))) * 50);
console.log(((data.state.val - data.oldState.val) * (3600000 / ((data.state.ts - data.oldState.ts)))) * 50 + ' Zeit: ' + ((data.state.ts - data.oldState.ts) / 1000));
}
Hier gilt es noch zu beachten, dass der Zähler eventuell die kWh Register nicht so oft aktualisiert und auch, dass bei der Übertragung Verzögerungen/Unregelmäßigkeiten für die Zeitmessung entstehen. Je unregelmäßiger die Daten daherkommen, desto ungenauer wird dann der berechnete kWh Wert, man kann dem aber entgegenwirken, indem die Berechnung über etwas längere Zeiträume durchgeführt wird (z.B. nur jede 4. Auslesung, also Differenzbildung zwischen erster und vierter Auslesung).
Man müsste auch noch etwas implementieren, dass der Leistungswert auf 0 gesetzt wird, wenn sich der kWh Wert für eine gewisse Zeit (z.B. 1 Minute) nicht mehr ändert, oder der gegengesetze kWh (Bezug/Lieferung) Wert sich ändert.
@robert-ke sagte in Smartmeter mit Landis+Gyr E650:
Die S0 Ausgänge würde der Energieversorger per Optokoppler rauslegen. Einen für Bezug und einen für Einspeisung. Aber Impulse zählen ist irgendwie oldschool.... daher der bis dato vergebliche Versuch direkt vom Zähler Werte zu bekommen mit denen man arbeiten kann.
Bei der S0 Messung müsstest du auch über eine Zeitmessung zwischen zwei (oder mehr) Impulsen die aktuelle Leistung berechnen, das wäre eigentlich nichts anderes.
Damit bekommt man übrigens auch sehr genaue und je nach Impulsverhältnis auch schnelle Werte übermittelt, vorausgesetzt die Eingänge bzw. der Task in der SPS sind schnell genug um eine ensprechende Zeitmessung durchzuführen. Mit solchen S0 Werten habe ich auch schon öfter Netzleistungsregelungen über eine SPS gemacht und auch die 15 Minuten Impulse dazu ausgewertet, damit landet man dann auch ganz genau bei den Werten welche das EVU bei der Abrechnung ausgibt.
Eine direkt Daten-Auslesung des Zählers wäre aber wirklich schöner, da man damit nicht das Problem hat ausgelassene Impulse (SPS Neustart / andere Unterbechungen) nicht zu zählen.
Das Ziel: Ja, Netzleistungsregelung. Somit wäre schon gut, wenn die Daten halbwegs rasch ankommen würden - wobei ich mit 1-3 Minuten leben kann. Wir schalten Final BHKW's ein oder aus und div. Verbraucher (E-Heizstäbe und div. andere Verbraucher)
Regelst du die Leistung dann eigentlich direkt mit dem ioBroker, oder wird der Wert an eine andere Steuerung weitergereicht welche die Regelung macht?