search

ioBroker / ioBroker.knx

connect KNX via eibd
http://www.iobroker.org
Other
50 stars 32 forks source link

Flags are still a MESS (even in v2) #231

Open trollvottel opened 2 years ago

trollvottel commented 2 years ago

So I took the plunge and bought a year subscription for 2000 GAs to be able to update to v2. Regretting already.

Issues persist: The KNX GA Flags are still a MESS!

The main issue I see here is: GAs in fact have no flags at all! It's the communication objects which have them!

From KNX perspective, that means for a DEVICE: "TRANSMIT" -> May transmit to KNX (Sends GroupValueWrite) "WRITE" -> Can be written to from KNX (Applies incoming GroupValueWrite) "READ" -> Can be read from KNX (Responds to GroupValueRead) "UPDATE" -> Updates internal value from KNX (Applies incoming GroupValueResponse)

Ok, fair enough. Now people argue how to set those in ETS, there are no communication objects for ioBroker in ETS! And they're correct, there aren't.

Therefore, IMO, the ioBroker adapter just needs to do the right thing, almost no configuration needed:

If there are line-couplers in a project, users need to make use of dummy-devices, which is a known workaround for other visualizations.

Some issues with current implementation:

I've seen the other issue reports regarding GAs, which I take as a "yes, me too".

chefkoch009 commented 2 years ago

Issues persist: The KNX GA Flags are still a MESS!

Don't understand the problem, it is explained in README.

The main issue I see here is: GAs in fact have no flags at all! It's the communication objects which have them!

You are completely right. Please show me a "GROUP"ValueRead on a communication object.

All GAs may "TRANSMIT" (Send GroupValueWrite if value gets changed within ioBroker)

Can you please explain, what "TRANSMIT" means, which flag do you specially mean?

All GAs must be "READ"able from KNX (Reply to GroupValueRead with GroupValueResponse with current ioBroker value)

No....why? Not every Groupaddress is readable in KNX.

All GAs must be "WRITE"able from KNX (Apply GroupValueWrite by changing ioBroker value and send ACK)

No...why? Not every Groupaddress is writeable in KNX.

If there are line-couplers in a project, users need to make use of dummy-devices, which is a known workaround for other visualizations.

It isn't new.... this is the way since years. (Gira HS, MT701,....). But this knownledge is required if using linecouplers.

"READ" does something completely different than what's expected in KNX world.

It is explained in README.

Why do I need to set "write" flag for GA in ioBroker to be able to send to KNX? In KNX world, "write" means KNX may write to this address and not the adaptor (see above)!

It is explained in README.

Why do you confuse users with ioBroker <-> KNX relation regarding states and flags in the first place? Each GA creates its own object in iobroker anyway. The GA Flags are a KNX-only thing and the adapter should behave to the KNX spec and nothing else!

This is for using esp. vis. Because some widgets don't support a state object and also many other IOT devices. To be able to combine all this components, thatswhy i confuse the users.

Why do I need to micro-manage my GAs in ioBroker in the first place? That feature IMO is rather useless and should be removed, KNX ETS is the ONLY tool to use to configure GAs and flags!

If your ETS project is configured properly, then you shouldn't need this.

I've seen the other issue reports regarding GAs, which I take as a "yes, me too".

F.e. which one?

I'm sorry, but I can't see any issue here. If you want me to help you, please contact me....maybe we can fix/clariefy some things.

trollvottel commented 2 years ago

Can you please explain, what "TRANSMIT" means, which flag do you specially mean?

https://support.knx.org/hc/en-us/articles/115003188089-Flags

In German, I'm talking about the "Übertragen" (Ü) Flag.

No....why? Not every Groupaddress is readable in KNX.

The GA itself, of course! If at least one communication object in the GA has the "READ" flag set, the device replies.

No...why? Not every Groupaddress is writeable in KNX.

The GA itself, of course! It's the communication objects, that either ignore a write or react on it (according to flags).

It is explained in README.

Explanations don't fix false design.

F.e. which one?

https://github.com/ioBroker/ioBroker.knx/issues/208

trollvottel commented 2 years ago

All GAs must be "READ"able from KNX (Reply to GroupValueRead with GroupValueResponse with current ioBroker value)

Re-thinking this, it won't be the best idea. Would be better to be able to configure this in ETS using a dummy-device with Read-Flag set which the adapter handles accordingly at project import. (Corrected in text above).

chefkoch009 commented 2 years ago

I already thought about a iobroker "knx-device" to catch to points you mentioned. But this is not as easy as it it sounds like.

trollvottel commented 2 years ago

Understandable, especially because of KNX certification stuff.

But IMO it would already help a lot, if the adapter behave in a best-effort manner, like I described. For example, it should be possible to send to KNX from within ioBroker without having to set any additional stuff.

trollvottel commented 2 years ago

Chefkoch, is it possible to schedule a meeting between us regarding the flags? I'm quite sure the adapter behaves wrong in a few situations and the readme is very confusing. Just to ensure we've heard both sides. You speak German, right? (Ich eigentlich auch)

trollvottel commented 2 years ago

Next bad example: Adapter doesn't read ALL GAs by default at startup. Only those GAs with READ flag set in GA Tool. This causes lots of warnings with newer Javascript adapter that warns about null values, e.g.:

javascript.0 | 2022-02-12 18:02:07.057 | warn | at processImmediate (internal/timers.js:464:21) -- | -- | -- | -- javascript.0 | 2022-02-12 18:02:07.057 | warn | at Immediate._onImmediate (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5708:41) javascript.0 | 2022-02-12 18:02:07.057 | warn | at Object.stateChange (/opt/iobroker/node_modules/iobroker.javascript/main.js:530:29) javascript.0 | 2022-02-12 18:02:07.057 | warn | at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js:1082:38) javascript.0 | 2022-02-12 18:02:07.057 | warn | at Object. (script.js.Präsenzmelder.Rückfall_Zwangsführung.DG_Kind_2:5:10) javascript.0 | 2022-02-12 18:02:07.056 | warn | getState "knx.0.Hauptfunktionen.Zentral.Hauptfunktionen_Zentral_Schlafen_Kind_2_(Schalten)" not found (3) states[id]=null

There is no point in NOT reading ALL GAs at startup.

chefkoch009 commented 2 years ago

There are a very lot of reasons, to do this not.

This adapter doesn't have to fix thinks in f.e. javascript parts. This is error handling of your scripts.

So please don't provide phrases such like "Next bad example". This doesn't indicate a bug or error anyway, instead it's a meaning.

So let's stay realistic and try to fix the issues.

trollvottel commented 2 years ago

No, this is not script-related. The Javascript-Adapter (not the script itself) throws the warning because of access of null-value in KNX object, which should not be possible at all (after initialisation). After initialisation, all GAs should have a value - At least if there is a GroupValueResponse. But the adapter doesn't send GroupValueRead on all GAs at init by default.

chefkoch009 commented 2 years ago

However....let's explain and fix it in online session.