I had a similar problem a few years ago and solved it with a LUA script: https://www.domoticz.com/wiki/Lua_-_Electric_meter_pulse_counter More recently I'm using ESPHome, so I've just submitted a PR which fixes the handling of `total_increasing` devices with MQTT AutoDiscovery: https://github.com ...

yes I know, it was in the beta for some time and it works fine but I hate that I can't force connect. It's hard set to 30 sec. Hm, that's the first time I've spotted that complaint. Why's it a problem? You can connect to the amp even if it's "off"... do you use a hard power switch with it? It ...

The 4.9700 stable release was made a week or two ago, containing built-in support for Onkyo amps.

Yes I did but then I have only the possibility of switching on and off, volume and zone 2 from my receiver. I would like the possibility of choosing my input (like radio). I the onkyo app is this possible why not in the plugin? Hm, that ought to work. In the models without NRIQSTN it should learn ...

@dwmw2: Would it be hard to add device and learning of radio channels for pre-NRI-devices? I'm not sure how we'd want to represent those as a device in Domoticz. It's not a simple selector switch like the input selector, since the presets only represent *some* of the available states of the tuner ...

There is an aggressive timeout for device discovery. It's been a while since I last paid attention but I seem to recall having to play some tricks to make discovery faster. Is the invocation timing out? Check the CloudWatch logs for your Lambda function and see what's happening...

Responses are a bit hard. You don't always get one. But it might be possible to cobble something together — perhaps with a timeout of 2 seconds, wait to see if anything comes back which has the first three letters of what was sent. There are use cases that wouldn't work for, though. But really.. ...

Thanks for all the work so far, now we wait till it's merged in a beta... Should be in the next beta build. For receivers without NRIQSTN support it'll learn the devices (per-zone volume, power, source selector) as it sees them change. And it'll learn the available sources as it sees each one ...

I've rolled those fixes into https://github.com/domoticz/domoticz/pull/1971

Still need to make it send the queries on startup, if NRIQSTN isn't supported. Real work intrudes though...

cant you just check the other QSTN types and set the state? Yeah, it could send QSTN at startup for any device which has previously been seen. There are caveats though, because the device sometimes doesn't respond if you send too much at once, especially if one of them is NRIQSTN. I probably need ...

OK, this should fix the support for models without NRIQSTN somewhat: https://github.com/dwmw2/domoticz/commits/onkyo-dev It still doesn't precreate devices; it needs to learn them. So turn each zone on/off and change its volume, and select every one of the inputs that it can manage. I still need to ...

If you turn the zones on/off on the amp ,and turn the volumes for each zone up/down, the devices come back? But just don't have the correct icon, yes?

What happens when you interact with one of the existing volume control devices, after the upgrade?

Edit: checked the document which i got from onkyo a time ago when i implemented my own eiscp stuff. My TX-NR545 supports NRI. When doing a manual NRIQSTN i just got a timeout. You mean, it's *supposed* to support NRI, but empirically, it doesn't seem to? The last version i used was just with pwr on ...

Lyrex wrote: ↑Friday 01 December 2017 12:12 Hey guys,

updated to the latest beta an now the native domoticz plugin does not work anymore for my TX-NR545. Anything i can do that it is working again?

Hm, I didn't think that should have broken. I'll check and fix it. Thanks.

(How do I delete a duplicate post? Cannot see how, from my phone...)

rizzah wrote: ↑Thursday 30 November 2017 15:26get

We probably just need to iterate over the known SLIxx commands and see which ones elicit a SLIN/A error response, and which ones work.

That is actually not a bad idea. The receiver type is delivered by the discovery. We could add an XML file per receiver model number that does not support NRI, and load the XML from file instead of the receiver. Ah yes, I hadn't noticed it; the built-in support doesn't do discovery yet and is just ...

Idea: receivers that doest support NRI. Could we create one monster json file that defines all the receivers and what those are supporting. https://github.com/miracle2k/onkyo-eiscp has that in a machine-readable form already. See https://github.com/miracle2k/onkyo-eiscp/blob/master/commands/zone3 ...