NEWS
MQTT ack=false forcieren?
- 
					
					
					
					
 Adapter setzen ihre AUSGANGS-State, d.h. jene States die einen Wert VOM Gerät liefern IMMER mit ack=true. Alles andere wäre falsch. Schau mal in die go-e Dokumentation, dort gibts ein Beispiel für Fronius 
 https://github.com/MK-2001/ioBroker.go-e/blob/main/docs/Readme.md#foreign-objects
- 
					
					
					
					
 hab ich schon alles durch  
 Die Beschreibung im screenshot sagt auch: "This Adapter is currently consuming only ack = false states."Wenn ich onlyAck wähle habe ich im log einen error: 
  wähle ich gar nichts von beiden - verhalten wie vorher ich hab eben ins github repo geschaut und die main.js geöffnet: EDIT sorry, screenshot ist ein paar zeilen zu hoch, weiter unte ist quasi derselbe text nochmals für die ack=true in Zeile 284 
 https://github.com/MK-2001/ioBroker.go-e/blob/main/main.js scheinbar wird nur die house consumption geprüft, wie ich das sehe, oder? 
- 
					
					
					
					
 @highpressure said in MQTT ack=false forcieren?: This Adapter is currently consuming only ack = false states. Dann poste das Problem entweder im go-e Wartungstopic (so es das gibt) und / oder mach ein Issue beim Adapter auf. Wie oben geschrieben, States die der Adapter xyz mit Werten aus dem Gerät befüllt werden IMMER ack=true haben. Nur States die DU als Input in den Adapter schreibts müssen ack=false haben. Das kann dann aber nur States des GO-E betreffen, die DU (z.b. via script) beschreibts. 
- 
					
					
					
					
 @mcm57 Vielen Dank, dann werde ich das im GitHub so tun  DANKE EUCH FÜR DIE HILFE! PS: habe ChatGPT4 den link zur main.js gegeben und um erklärung gebeten weshalb das so ist: In the code, checking for ack = false is crucial as it helps ensure that only state changes initiated by external inputs are processed further in the onStateChange method. When ack is false, it indicates that the state change is new or unacknowledged, prompting action to handle this change. If ack were true, it would signify an acknowledged or system-generated state change, which doesn't require further action in this context1. 
- 
					
					
					
					
 Möglicherweise hat der Adapzter den (in meinen Augen falschen Ansatz) dass hier ein vom User beschreibarer State in der Config eingetragen wird, z.B. 0_userdate.xxxxx. Wenn du diesen eigenen State per Skript beschreibts kann da natürlich ack=false stehen. Der Ansatz ist aber m.E. falsch, da für das Bearbeiten des States als Input bei einem Adapter gilt: - Input State === eigener State der Instanz -> ack=false
- Input State === foreign State einer fremden Instanz -> ack=true
 Es mag Ausnahmen geben - hier seh ich aber keine. 
- 
					
					
					
					
 @highpressure sagte in MQTT ack=false forcieren?: EDIT sorry, screenshot ist ein paar zeilen zu hoch, weiter unte ist quasi derselbe text nochmals für die ack=true in Zeile 284 Gerade nochmal den Code genauer angeschaut. Wenn state.ack = true, dann geht es ja hier weiter:Und dann wird geprüft, ob onlyAckauch auftruesteht. Sollte also funktionieren.@highpressure sagte in MQTT ack=false forcieren?: scheinbar wird nur die house consumption geprüft, wie ich das sehe, oder? Nein, werden alle geprüft. Siehe 3x caseda drüber. Code passt aus meiner Sicht.Teil doch am besten nochmal ein Log, wenn Du überall onlyAckangehakt hast.@mcm57 sagte in MQTT ack=false forcieren?: Möglicherweise hat der Adapzter den (in meinen Augen falschen Ansatz) Der Adapter bietet doch in den Instanzeinstellungen die Option, ob man jeweils ack: trueoderack: falseverarbeiten möchte. Mehr Optionen braucht man ja nicht. Damit ist alles abgedeckt. Auch dieser MQTT-Fall hier.
- 
					
					
					
					
 @haus-automatisierung said in MQTT ack=false forcieren?: Der Adapter bietet doch in den Instanzeinstellungen die Option, ob man jeweils ack: trueoderack: falseverarbeiten möchte. Mehr Optionen braucht man ja nicht. Damit ist alles abgedeckt. Auch dieser MQTT-Fall hier.Wenn er das tut ist das voll in Ordnung. 
 Ich hatte nur - ohne den Code zu analysieren - nach dem hier geschriebenen einen anderen Einsruck.
- 
					
					
					
					
 Die gezeigt Fehlermeldung erscheint, wenn eines der auszulesenden Objekte keinen Wert, bzw. Keinen numerischen Wert beinhaltet. Bitte stelle sicher, dass alle Objekte eingetragen sind. Und in deren Values auch reale Werte eingetragen sind. Welche Werte bei der Berechnung berücksichtigt werden ist in der Formel bei den Einstellungen ersichtlich. M.E. Hat die Fehlermeldung nichts mit ack zu tun. 
- 
					
					
					
					
 go-e.0 
 12309 2023-10-11 14:03:26.539 silly States user redis pmessage io.mqtt.0.PVGrid.total.pv_power.state/io.mqtt.0.PVGrid.total.pv_power.state:{"val":5288,"ack":true,"ts":1697025806536,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1697025806536}go-e.0 
 12309 2023-10-11 14:03:26.537 silly States user redis pmessage io.mqtt.0.PVGrid.total.load_power.state/io.mqtt.0.PVGrid.total.load_power.state:{"val":5770,"ack":true,"ts":1697025806536,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1697025806536}go-e.0 
 12309 2023-10-11 14:03:26.529 silly States user redis pmessage io.mqtt.0.PVGrid.total.battery_power.state/io.mqtt.0.PVGrid.total.battery_power.state:{"val":-208,"ack":true,"ts":1697025806528,"q":0,"from":"system.adapter.mqtt.0","user":"system.user.admin","lc":1697025806528}Das sind auch die Foreign Objects aus dem Setup, die liest er ja scheinbar auch aus und wie im silly log zu lesen sind sie nicht 0.  
- 
					
					
					
					
 @highpressure Du hast onlyAck ja immernoch nicht angehakt  
 
		
	 
		
	