Not working

[Hansontech190]

Thanks for implementing this. I've just installed a new instance of HA as my previous install was very old. I'm running eDIN+ with SW00120.2.4.1.43.

The integration found most of my eDIN components - I have a very large system and it's found 91 devices at present. However when I switch any scene on nothing happens and the switch in HA returns to off position.

Any ideas?

[sftgunner]

Hmm, interesting. My best guess would be that your eDIN+ setup involves multiple scenes with one channel in (e.g. in the image below output 7 wouldn't work because it has scene 2 dedicated just to it, as well as scene 3, whereas output 1 does work as the only scene that contains exclusively channel 1 only is scene one). This is as mentioned in #7 - thanks for submitting the issue; I'll see if I can get a fix working asap!

[sftgunner]

Out of curiosity, what types of device does your setup contain? There could also be a few pieces of hardware that I don't have access to that might be behaving unusually - I'll sort out Issue #7 first, as that is the most likely culprit (and has been causing issues for my setup!), and if that doesn't fix it, then it might be time to look into logs etc. I'll update this issue when I've made some progress!

[Hansontech190]

Thanks for the replies.

You're correct that I have multiple scenes with channels allocated! Sounds like that is the problem.

I have the following in my system: 5 x 8x2A Dimmers 3 x 8CH Input/Output Modules 3 x 4x5A Relay Modules (I don't think these are supported in the integration yet but have been discovered) 15 x SGP55 10 Button Plates

Another point to make is my system is password protected for the Configuration. This doesn't matter for control as you can send IP commands for switching without authentication but thought I'd mention it just in case.

[sftgunner]

I've sorted the aforementioned issue - it could be worth trying this again now with v0.5.5, but looking at the gateway developer documentation I think I might need to integrate some form of authentication if you're using accounts. Do you know if it's easy to disable accounts on the NPU once they're enabled (so I can test any changes I make to the auth workflow still function whether accounts are activated or not)? I've also noticed while going back through the code that I haven't added support for the 8Ch I/O module, but rather the EVO Contact Input module instead. In theory, they should both work very similarly from what I can tell, so I'll try and add beta support for it in v0.5.6 (shouldn't require much change to the code).

[Hansontech190]

Thanks for the update, which I think I've installed ok! I'm still getting used to HA after being away from it for several years. I removed the integration and added again which I'm assuming pulls the new version? Any way to check which version is running in HA?

Lights still not working except for one light in my utility which I think is due to it being set on only one scene.

User accounts can be disabled by simply removing the password for the account. However I don't think user accounts matter with the API control Mode have implemented as there appears no authentication needed when sending commands. I use Flic buttons for controlling a lot of scenes and these don't require any authentication.

[sftgunner]

Good to know re: authentication! Simply removing and re-adding the integration through HomeAssistant doesn't pull the new version, unfortunately - you have to update through HomeAssistant Community Store (HACS), assuming that's the method you followed to install it in the first place. To update through HACS, it might already prompt you to update the integration right on the HACS dashboard, or alternatively if you click through to the eDIN+ integration, and then press on the three dots in the top right, there should be an option to "update information" (see screenshot below from my HA install that's still on v0.5.4). Generally HACS automatically scans for updates every 48 hours, so it might not have picked up the new version automatically yet. Once you've installed the update, HACS should prompt you to reboot. To make sure that everything is fully up to date after rebooting, removing and re-adding the integration in HA itself again (once updated through HACS) would be a good idea (as this forces the integration to re-discover your eDIN system). Assuming you still hit issues, any errors or warnings in the logs could be useful (if these don't yield anything useful then next steps will be to enable debug logging, but with any luck the update might fix things before getting to that point!). If you're confused or I haven't explained it properly, please feel free to ask - I remember exactly how overwhelming HA felt when I first started using it, let alone trying to deal with HACS!

[sftgunner]

As a sidenote, I believe the version number in the top left of the screenshot above shows you the version of the integration installed on your system (with that screenshot taken when on v0.5.4), which you should be able to get to on your system by clicking on the following link: https://my.home-assistant.io/redirect/hacs_repository/?owner=sftgunner&repository=edinplus-integration&category=integration

[Hansontech190]

Thanks and apologies, I should have seen that update. I was looking at the integration itself rather than the HACS integration entry!
The switching is now working but I notice the channel is acting as a normal switched entry rather than normal entry - the channels on eDIN can be configured as simple switch or switch normal allowing for dimming. I configure my lights to dim up/down over a 5 second timespan. The HA integration simply switches on/off. Perhaps that's intentional to allow HA to do the dimming?? Have attached screenshot of one dimmer showing one channel set for normal switching and the others on normal.

[sftgunner]

No worries at all! I'm afraid I'm not entirely clear as to the different behaviour between Normal and Normal Switched - I wasn't aware those settings existed, so I'm sure it'll be possible to add that behaviour into the integration. If you'd be able to elaborate on the difference that would be much appreciated! At the moment I've got all of mine left as the default "Normal" mode; I'll do some playing around on my setup as well. In terms of fading, the integration uses the $SCNRECALLX or $CHANFADE command with a fade time of 0 at the moment - I'll have a look and see if there's a way of reading the default fade time for the overall system or the fade time for a scene and implementing that instead.

[sftgunner]

While I can use $SCNRECALL and $SCNOFF to turn scenes on to specified brightness and 0% brightness with the pre-defined fade times, there's no way I can immediately spot that will allow e.g. 50% brightness (although I'll have a closer look at the docs to see if I've missed it), without also having to specify the fade time in the code. For individual channels (that don't have a unique scene that can be used as a proxy), $CHANFADE is the only option, which again requires an explicit fade time. What I might be able to do is allow a configurable global fade time on setup; ideally I'd just read the default fade time from the eDIN+ system here, but I'm not sure how to access that at the moment. Further reading required; will update as/when anything to report.

[Hansontech190]

Thanks for the efforts here, really appreciated. I think I've spotted where the problem is but I can't identify why it's happening. If I do a scene recall with a simple http call then the scene comes on/off with the correct fade up/down time and the correct brightness for that scene. When I activate the same "light" in HA, the light comes on/off immediately and at 100% brightness. I could be totally wrong here but it looks like HA is triggering the channel on the dimmer and not the scene. Not sure how it's doing that as if you've used $SCNRECALL then it should be replicating that scene. I have a couple of devices which send both $SCNRECALL & $SCNTOGGLE to the NPU and these all recall the scene correctly. I've attached a screenshot from my system. The Dining On scene is number 3, and if I recall that the lights come up to 80% over 5 secs. If I do the same in HA the lights come on 100% immediately. Does any of the above make sense??

[sftgunner]

That makes perfect sense, and I think I can understand why - the key point is the difference between the $SCNRECALL and $SCNRECALLX commands - for the former it will obey all the preset scene fade times etc, while the latter has to be configured while sending the command (i.e. it will override the defaults). The advantage of $SCNRECALLX is that you can adjust the brightness of the scene (so in your screenshot above, if you were to set scene "Dining On" to 50% brightness in HA, it would set to 50% of the total 80% brightness of the scene = 40% actual brightness of the channel. Because of the way HA deals with light entities, sticking with $SCNRECALLX is preferable due to the flexibility, but I'll make sure there's a way to add a fade time, either inherited from Mode Lighting or worst case manually configurable inside HomeAssistant. Just to clarify, what was the difference you were expecting between a Normal and a Normal Switched channel? From context I'm assuming it's to do with the way it fades, but I'm still not entirely clear (just so I can document it for future reference correctly!)

[Hansontech190]

Thanks that makes sense now. I'll need to play around in HA to see how this works.

Yes apologies I forgot to define Normal and Normal Switched.
Normal: Channel behaves as a full dimming channel allowing the connected source to be set at any desired dim level and a fade up/down time specified. Normal Switched: Channel behaves as a simple switch with no dimming or fading - this is important for LED lights which cannot be dimmed, the channel should be set to Normal Switched. Same for any connected load which is simple on/off - doesn't have to be a light connected to the channel, can be any load under 2A.

If you change the channel type you'll see a different icon:

Hope that makes sense?

[sftgunner]

Perfect - thanks very much! I've got some time over the next few days, so I'll play around and will try and get those changes through ASAP.

[jeff-heine]

Hi. I though I could add a bit of background to the various commands and properties.

Re: $ScnRecall vs $ScnRecallX and fade times. The thinking about these 2 commands is that the whole point of scenes is to set the channel levels and fade time to what you desire, so a simple recall that uses these settings is useful. However, it is recongised that you may want override these settings and do your own thing, hence $scnRecallX, but then you are on your own. In practise, the most common use case to the use $scnRecall to do an initial recall, then use $scnRecallX to do adjustments via a slider. There are $scnNudgexxx commands to do adjustments via buttons rather than slider. An advantage of scnNudge over scnRecallX is that scnNudge can make channel levels go higher than 100% scene (up to 100% channel level) whereas scnRecallX is limited to 100% scene level. Note that from ver 2.4.2.x (Gateway ver 2.03) a set of new $scnAdjustxxx commands have been introduced to replace $scnNudgexxx to support colour channels in scenes better. So these Nudge/adjust commands might be a good way to get brighter than 100% scene recall.

Re: Normal vs Normal Switched channels. The advantage of using Normal switched property for non-dimmable channels is that you can send channel Fade commands or perform scene fades to the channel without worrying about blowing the fixture up. They can be mixed in scenes with dimmable channels, and will be switched on and off synchronously with the dimming channels on & off. The default is to switch the channel On at level 1 and above and off at level 0, but this can be adjusted to a higher level if that looks/works better with the other dimmable channels.

[sftgunner]

Hi Jeff, very many thanks to you and the rest of the Mode Team as ever for all your help on this!

With $scnrecall vs $scnrecallx, I suspect we're back to the original point of "should control be done primarily via the NPU or via HA", where the goal (in my view) should always be to prioritise for the NPU where possible. Adding $SCNOFF I think is a bit of a no-brainer, and $SCNRECALL is an easy option for normal switched channels - the interesting part being how HA will deal with $SCNRECALL as the "turn_on" function, but then using $SCNRECALLX if any further brightness adjustments are required (which I'll experiment with today) - it will depend on whether HA expects the turn-on command to turn on to previous brightness level, or whether it will be happy with the fact that it will always turn on to 100% when toggled, unless the brightness is explicitly stated. It's worth noting this is all in the scope of the "scenes as a proxy for individual channels" part of the code - on my todo list is adding support for calling scenes programatically in HA using "Services", where you can truly treat the NPU as the priority, but I know that as an end-user services are always a bit more fiddly to implement outside of automations.

Good to know that the NPU will probably already have saved some fixtures from my code re: normal vs normal switched channels! I'll make sure they're treated as on/off only going forwards

[Hansontech190]

Yes many thanks to Jeff for the input.

Thinking a bit more about this I'm thinking $SCNRECALL is a better option for most eDIN+ users. The likelyhood is that users/installers will have configured scenes already within the eDIN config to give a particular brightness and fade time. Certainly with my own system I've spent many years getting all the scenes just as I want them and rarely, if ever, adjust the brightness. I think just recalling the programmed scene from the NPU would be preferable with the ability within HA to then adjust the brightness with a slider. Having to configure HA with all the preconfigured scene levels and fades would seem counterproductive for most if these have already been configured on the eDIN NPU.

Just a thought but not sure how easy it is to change and implement this.

[sftgunner]

Agreed on both counts about trying to minimise the amount of configuration needed through HA and inheriting from the NPU wherever possible. So in some progress, fade times are now implemented using $SCNRECALL/$SCNOFF/$SCNRECALLX as appropriate (thankfully the scene recall time is also in the /info?what=levels endpoint, which I've used when $SCNRECALLX has to be used to adjust the brightness (added in v0.5.6). However, there isn't anything in the API that signifies whether a channel is Normal Switched or Normal, which means I can't change how they are presented in the UI. It's not a massive problem given the NPU won't let any dimmed values be sent to the fitting as Jeff mentions above, but means that the light entity in HomeAssistant will be presented as a brightness-adjustable light, even though it isn't in reality. To keep these issues tidy and easily referenceable, I'm going to close this now (as the core original issue has been addressed) - @Hansontech190 thank you very much for your feedback and help; if you hit any other bugs, glitches or unexpected behaviour please open another issue and I'll try and help as soon as possible.