Failed to Setup #13
Comments
|
Ah, sorry you're hitting this! Could you have a look in logs to see if there's a more specific error message and report back if there is? https://my.home-assistant.io/redirect/logs/ |
|
No problem. Here's the error log: Logger: homeassistant.config_entries Error setting up entry 192.168.1.140 for edinplus |
|
Ah, that's a relief - should be an easy fix (was part of the changes to make logs more human-readable). Will push a quick fix through in v0.5.7 shortly. Many thanks! |
|
Should be fixed in v0.5.7 - if you can give it a go and let me know if it's worked for you, that'd be much appreciated. |
|
Thanks so much for quick response. Logger: homeassistant.config_entries Error setting up entry 192.168.1.140 for edinplus Also second error in log: Logger: custom_components.edinplus.edinplus Unknown input entity of type LCD Wall Plate found in area Master Bedroom as with id edinpluscustomuuid-28-1 However I think this is down to the integration not recognising the Mode LCD control plate? I have one of these in the system which I think is confusing it. Link to LCD plate: https://www.modelighting.com/products/evolution/controls/evo-lcd-plate/ |
|
Ah, sorry, I see what I did wrong now! In the most recent set of changes I tried to modify the code to ignore any input devices it doesn't know how to deal with (before it was blindly creating them as devices in HA that couldn't then be interacted with in any meaningful way). Will try and push a second fix and will verify a bit more thoroughly on my end before committing a release this time, sorry! |
|
Right, have added the missing |
|
Thanks again. Yes that's fixed it with all lights now working I think. It's still just switching on without the fade up/down time but not sure if that's something which you still need to implement? i.e. taking the scene from the NPU rather than $SCNRECALLX. However it could also be the config in HA as I've left everything a default when installing the integration. It's just prepopulated the cards with the lighting channels. |
|
Another thing I've noticed is the state of the lights isn't reflected in HA if I switch on from a faceplate. The light shows off in HA even if on. |
|
Hmm - the lights should be updated in HA if switched on from a faceplate - I'll do some investigating on my setup to see if I can replicate/diagnose. As for the first comment, the fade time is implemented, but it's here we run into slight issues in interoperability between HA and the NPU, and I'd certainly appreciate additional user input/feedback. Apologies for the verbosity of the below explanation, but I thought clarity was probably the priority over length! HomeAssistant interprets lighting channels (i.e. the outputs of the DIN Dimmer modules) as physical lights in the real world, and that's what's appearing in your HA instance. These lighting channels can be interacted with using the $ChanFade command on the NPU, which is what happens by default. However, this doesn't work very well with the native NPU scenes. For example, say I have a light output A, that has two scenes assigned to it on the NPU (scn1 = 100% brightness, scn2 = 0% brightness), with two physical buttons (btn1, btn2) set to each trigger a scene respectively. If I set light output to 100% brightness using ChanFade, and then try and toggle scn1 using btn1, nothing appears to happen, as the light is transitioning from {100% brightness, no scene active} to {100% brightness, scn1 active}. A second toggle on btn1 will then turn the light off, as expected, and a third toggle will continue as expected, turning to 100% brightness, a fourth would turn it off, and so on. The point being that ChanFade removes the light output from being associated with any particular scene, which results in an unexpected extra input required when toggling. If btn2 is set to simply recall scn2 (i.e. light output A = 0% brightness), that will work every time. However, the NPU prefers working in terms of scenes (scn1 on, scn1 off, scn1 50%), but because two different scenes can both contain the same light output (and in the case above for scn2, can be set to 0% brightness for a given channel), I can't simply pass scenes through to HA as "lights", as the internal state monitoring inside HA isn't designed to deal with something like scn2 as a light. My solution to this was what I call "proxy scenes". This is where you set up a scene on the NPU to only affect one channel with 100% brightness (see scenes 1, 2 and 5 in the screenshot below, and ignore the scene names, which I need to fix!). The integration will look for scenes that only have one output channel associated with them, with that output channel set to 100% for that scene (which eliminates scenes 3, 4 and 8), and instead of using ChanFade to control those lighting outputs in HomeAssistant, it uses a selection of ScnOff, ScnRecall and ScnRecallX as discussed above (i.e. using that scene as a proxy for the lighting channel). The other key benefit here is that you can assign fade times to scenes, but critically, you can't assign fade times to channels through the NPU interface, as the ChanFade command is not standard expected usage. The interesting bit is that ChanFade does accept a fade time parameter, but it's how the fade time should be determined if there's no proxy scene that's the tricky bit - I could take the mean or mode fadetime from all scenes that the channel appears in (but this could result in odd, unintuitive behaviour depending on the setup), or I could have this as a blanket setting during configuration for all lighting channels, but then you lack the customisation that is the strength of the eDIN+ system. Obviously having it configurable for each lighting channel in HA could be an option, but as you mentioned in another comment, most people have spent ages setting up their eDIN+ system to work perfectly on the NPU, and having to go through tens of lighting channels in HA setting them all up again is far from ideal This is why I left the ChanFade time as 0, on the basis that it probably won't result in optimal behaviour for anyone, but it's the easiest to intuitively expect and understand, with the option of setting up Proxy Scenes if you want/need the fadetimes and intuitive toggling, and the "least bad" overall in my mind, but I'm very receptive to suggestions - this was done based on the two eDIN+ setups I've come into contact with, but I'm aware there are so many different permutations and configurations that I likely haven't considered!
|
|
Thanks for the explanation. I think you've hit the nail on the head with this comment: < However, the NPU prefers working in terms of scenes (scn1 on, scn1 off, scn1 50%), but because two different scenes can both contain the same light output (and in the case above for scn2, can be set to 0% brightness for a given channel), I can't simply pass scenes through to HA as "lights", as the internal state monitoring inside HA isn't designed to deal with something like scn2 as a light.> I didn't realise that HA couldn't cope with importing a scene as a light. Think that's where the problem will be as not sure how you can ever replicate the eDIN+ configuration if HA can't cope with importing a scene. I think they're be a lot of conflict due to the way eDIN+ can combine lights/channels into multiple scenes. However I think Lutron's system also does something similar but it may be implemented differently. When you mention proxy scenes, how would this be implemented in HA? I know you can set scenes up for various scenarios but after playing with this briefly I don't think it provides the flexibility that the config already in eDIN+ has. Is that what you mean by a proxy scene? You're also 100% correct in that everyone's configuration for eDIN+ will be different with various levels of complexity. For instance in my own setup I have various System Modes which need to be active/inactive for various scenes to activate. Overall my setup is quite complex in terms of what it controls. Anyway if I can be of any help let me know and thanks again for all the efforts. |
|
Scene toggling behaviour is surprisingly full of gotchas for something that seems 'obvious'. Toggling scenes on & off needs to know the state of a scene, ie. if it is on or off. Although it seems like a simple statement, when different scenes control the same channel and you mix channel operations with scene operations the state of the scene turns out to be surpisingly difficult to define. And it turns out to be very context sensitive and subjective. Because scene state can be so subjective, eDIN+ makes a simple rule - controlling channels and controlling scenes do not mix - stick to one or the other. So introducing proxy scenes is a good way if you use scenes and individual channels need controlling, as this has a better chance of tracking scene states. An exception is when defining or editing scenes where indvidual channels need to be adjusted. But in this case disruption to scene states is usually less important. An example of the subjective nature of scene states is as follows. Suppose you have an All on scene for a room that includes a table lamp/bed side lamp. You recall the All on scene but then have a button that turns off the table lamp. Should the All on scene still be active/on or not? Some people think that it should not, because all the lights are not on. Other think it should still be on and essentailly the room is lit, especially if a toggle active is against the All On scene, so that a toggle of all on will turn the lights off. Often require behaviour varies from room to room, or even plate to plate within a room. It is impossible to generalise to every situation. eDIN+ does have a number of settings for scenes that affect how the scene state is determined, but they are mostly relegated to advanced settings as this topic is a lot deeper than at face value. |
|
Sorry for the delay @Hansontech190 - in response to your last query with proxy scenes, it's effectively a way to modify the eDIN+ configuration to make the NPU work more nicely with HA - the trick being that you set up a scene on the NPU for each channel where it's set to 100%, and then the HA integration will read that information and will then interact using those NPU scenes (which are the "proxy scenes") rather than interacting with the channels directly. The other potential compromise could be to simply add a blanket fade time configuration option in HA - you lose the configurability, but if you have the majority of your lights on a 5 second fade time, then that could be implemented when interacting with any channels via HA. I'd need to read up on how to add that information as an option, but I'm sure it'd be possible! In short though, not ideal, I'm afraid! You're absolutely right that HA "Scenes" are a totally different beast - the "proxy scenes" is literally just a name I came up with that is applicable to this integration and this integration only! |
|
No apology necessary, your efforts are very much appreciated. Sorry for not understanding how HA integrates with eDIN+ but I’m basing my limited understanding with how I’m controlling eDIN+ outside of the app and faceplates. I’ve an app based remote which I’ve configured with the eDIN+ commands like $SCENEON and $NUDGEUP etc. I then create a trigger button within the app which simply recalls the scene number as listed on the eDIN+ configuration. All this does is recall the scene with all its settings. The problem is there’s no feedback so you can’t see from the app what state the scene is in. The eDIN+ app on the other hand shows the status of each scene but is limited in what it can do. The above is probably no help whatsoever but I’m trying to understand why HA can’t simply recall a scene rather than integrate with a channel. |
|
Also no need to apologise on your side - it's certainly not the most straightforward thing! So the fundamental part is that I could add the functionality for HA to read scenes - the discovery of them isn't the difficult part. The tricky bit is then deciding how to pass the scene through to HA in a way that HA can understand. The problem is that HA expects certain types of device, or "entity" - lights, switches, water heaters... even more abstract stuff like "Siren", "Speech To Text", "Update" and so on (there's a full list of them on the sidebar here: https://developers.home-assistant.io/docs/core/entity). When you're writing an integration, you can only expose things to HomeAssistant as being one of these entity types (e.g. as a light, or as a switch, or as a cover etc). Consequently when it came to designing the code that could effectively translate between eDIN+ and HomeAssistant, I had to choose a) which parts of the eDIN+ system I was exposing to HomeAssistant, and b) how I was exposing them (i.e. as what device type). The problem lies in the fact that for what is primarily a lighting system, HA expects to interact mostly using "Light" entities - so far so good. However, the NPU expects to interact mostly using "Scenes". The difficulty lies in making these two fundamentally different concepts compatible. Scenes can be weird, and they don't reliably behave in the same way as "lights" as HA understands them - as mentioned above, you could have empty scenes, or scenes that set some lights to 100% brightness while simultaneously setting other lights to 0% brightness, or just scenes that set a bunch of lights to 0% brightness. These can't usefully be interpreted as "lights" due to the bizarre logic and incredibly confusing interface that would result in HA, not to mention that scenes can interact with other devices through the relay and I/O module! Ok, I thought initially, no problem. If I can't use eDIN+ scenes as HA "lights", then why don't I just import the eDIN+ channels as lights, and eDIN+ scenes as HA "scenes". However... the issue here lies in the fact that HA treats "lights" as first-class citizens, and "scenes" are a lot harder to access/use... and equally eDIN+ treats "scenes" as first-class citizens, and "channels" are more of a "if you need to use them, they're there, but we'd really recommend using scene control instead". There's also a slight issue that HA "scenes" work a bit weirdly (to me, anyway!) - you can turn them on ("activate them") using the UI or as service calls, but as far as I'm aware there's no ability to turn them off again or set to a percentage of their maximum brightness, for example - the latter of which is a key feature with dimmable fixtures in the eDIN+ system (especially with the new Oslo controls!). To make matters worse, scenes in HA aren't stored as being "on" or "off" (they're so-called stateless), so there's no way of knowing what scenes are active on the eDIN+ system by looking at HA, as there's no feedback (i.e. I'd only be able to use $SCENEON). Consequently, I created these "proxy scenes" to try and bridge the gap to keep both HA and the NPU on the eDIN+ system as happy as possible, as you are then interacting with the preferred entity for both (eDIN+ "scenes" and HA "lights"). To make sure that these scenes work as HA is expecting, I had to enforce the 100% brightness, single channel rule - the brightness issue could probably be fixed (although it would require a bit of a re-write, as brightnesses are currently read from the channel directly, rather than the proxy scene if it exists), but the single channel requirement has to persist by the very nature of a proxy channel. Ideally though, I'd like to add support for all eDIN+ "scenes" being imported as HA "scenes" in addition to this slightly hacky solution, to give maximum flexibility to the user, but the main issue is a lack of examples for me to draw upon - the only integrations I'm aware of that implement them in this way are the Phillips Hue, MQTT and KNX integrations, all of which are very mature and quite complex! The direct documentation available is also... not particularly detailed with no information on how to match lights to scenes as you create the scenes, for example. Hopefully the above makes sense - I'll have a look into adding HA "scenes" - if nothing else, having the ability to trigger scenes using service calls is another good compromise solution, but the fundamental problem comes from trying to marry two systems that have slightly different design philosophies, I'm afraid. Sorry that's a bit of a wordy message - the key answer to your question is that HA could recall a scene in addition to integrating with a channel, but the difficulty is what HA entity you use to trigger that command. I think using a HA scene or HA service call to trigger the eDIN+ scene recall would make the most sense, and the latter has been on my "I really should look into adding this" list for a while, but my immediate priorities are validating and adding full support for the keypad, I/O module and Relay modules, all of which have been recently added to my test setup. |
|
Really appreciate that explanation and taking the time to explain. That all makes sense and I can now see the problems! Lighting control systems can get very complex and Mode Lighting have resisted altering the original software interface for some time due to that. eDIN was always designed as a much simpler control system than Evolution but I understand they decided to completely redesign the backend Gateway when they released eDIN+. However this then makes integration difficult for the developer. So in essence, if total control of eDIN+ was needed in HA, a proxy seen would have to be created for each lighting channel and this set to 100% - is that correct? What about the I/O channels and Relay Channels, do these also need a proxy scene? The relay channels should be relatively straight forward as these are simple switches, on or off. I/O channels may be a bit more complex as these can be simple contact inputs or PIR inputs. Thanks again for your time. |
|
That is correct - a proxy scene would need to be created for each lighting channel and set to 100% - I'm aware this is a bit of a pain! I/O module contact inputs should already work as expected, and 0-10V output should also work just like a normal dimmable light at the moment (i.e. needing a Proxy Scene to work with fading). |
|
Perfect many thanks. I'll make some time and build those proxy scenes. It shouldn't take too long as the number of channels I have on dimmer modules is only around 38 or so. Is there a recommended naming convention which would help for the proxy scenes or should they be named simply with the light they control - eDIN used to recommend naming scenes by area:light but have moved away from that now. |
|
The naming scheme shouldn't matter - the integration will read the name from the Channel, not the scene, if that makes sense, so whatever makes the most intuitive sense to you would be what I advise. You'll notice in the screenshot above half of the scenes in my test system are still unnamed! If I were you, I'd recommend creating a couple of those scenes and then checking they work properly in HA (you might need to reload the integration first) before proceeding with all 38 - do let me know if you hit any issues or they don't work as expected. |
|
Thanks again. Just had a quick play with two channels and they're working fine and feedback appears to work too. However the fade up/down time is set at zero so the channel/proxy scene comes on immediately. I think you mentioned this may be an issue previously - sorry I've lost track of where we got to with fade times. I have the default fade time set to 5s within eDIN defaults and the two new proxy scenes are set to 5s also - see attached. 
|
|
Hmm... the fade times definitely should be read by HomeAssistant - they'll read the scene fade times (as there's no obvious way to programatically access the default recall time in any case!). |
|
No problem and thanks for the updates. I experimented with changing the fade time in the proxy scene but this having no effect when I switch on/off in HA. |
|
Good to know - I would guess that it's not matching the proxy scenes correctly, so I'll make sure that the debug logs are nice and verbose for that bit of the code before release! Functionality has all been added for v0.6.0; I'll do final tests tomorrow (Friday) and should be then good to go for the weekend, all being well. |
|
Apologies for late reply, I've been busy with work! I'll have a play with the new release and let you know how I get on. Thanks again. |
|
Oh dear failed at first hurdle. After updating I restarted HA and removed existing NPUs and then added again. However get the failed to setup error. Have shown error log below: `This error originated from a custom integration. Logger: homeassistant.config_entries Error setting up entry 192.168.1.181 for edinplus |
|
Sorry for the delayed response - I've been away from my test setup for a while. Just to check, does your wall plate have a name in eDIN+? I't looks like the problem is somewhere in the naming of the wall plate entities, but I'm not able to replicate the error with my own set up, either with a name for the wall plate or without... (see example below without a name) |
Small changes to help troubleshoot #13
|
I've pushed v0.6.2 to try and help troubleshoot the issue going forward, and hopefully should get your HA integration back up and running again |
|
Hi. Just installed update but same error. `This error originated from a custom integration. Logger: homeassistant.config_entries Error setting up entry 192.168.1.140 for edinplus During handling of the above exception, another exception occurred: Traceback (most recent call last): To answer your query all the plates are named but I have one LCD plate and the rest are old SGP plates. Didn’t get this error on your earlier versions - not sure if that helps!? Let me know if you need anything else to debug. |
|
Hmm - sorry about that! The LCD plate and SGP plates weren't properly supported before 0.6.0, which is why this error has appeared now, but I'm slightly confused as to why the regex to get wall plate information isn't working - I'll do some more investigation and will get back to you. |
|
Not a problem. It probably won’t help but happy to give you a copy of my eDIN config file. I know you don’t have the same hardware but if it helps let me know. All the Best, Andy |
|
Much appreciated! The easiest thing to troubleshoot would be a copy of your "Names CSV" file - you can download it by going to "http://NPU_IP/info?what=names". I'm sure there's something very obvious I'm missing; I'm just going through the eDIN+ documentation now to see if I can figure out what it is, but a copy of your Names CSV would certainly speed up the process, if you're able |
|
Have hopefully attached. Good luck! |
|
Ah, I was right, it was a really stupid mistake - the regex would only match for wall plates located in areas 1-9 (i.e. it would only match if the room number had a single digit, rather than the room number being of any length) - just a case of a missing "+"! |
|
Have pushed 0.6.3 with the bug fix - fingers crossed this does the trick! |
|
Thanks for the update. That’s sorted the issue. However the fade time is back to immediate instead of the set fade up/down. I’ll have to make sure I’ve added the correct proxy scene but I haven’t changed anything since adding two test proxy scenes and these are set to 100% and 5s fade time. However when activating in HA they immediately go to 100%. This may be my mistake but I need more time to investigate. Just wanted to let you know that no errors now produced by HA. :) |
|
Ah, I had a horrible feeling this might be the case. By way of troubleshooting, if you look in the HA logs, can you see if it's completing the proxy scene mapping correctly? You're looking for something that looks a bit like this: If you go to "Load full logs" when on the log page, it should be reasonably close to the top (just after a load of entries saying "Input entity found..." and "Creating device in registry...". |
|
You'll need to enable debug logs to get those messages - I think there might be a way of doing this via the GUI now, but I've always done it by adding the following to my logger:
default: warning
logs:
custom_components.edinplus: debug |
|
Thanks for the replies and apologies for delay but just getting some time to look at this. Doesn't look like it's mapping the proxy scenes. It seems to be using the normal scene numbers (I've setup proxy scenes for just two channels - Kitchen Ceiling & Kitchen Dining which have scene numbers of 211 & 212). However the original scenes for these areas appear to be what the integration is using and not mapping the proxy scenes. Any ideas?
|
|
Ah, I think I might have found the error - very similar as before (turns out it's very easy to make a typo on regexes that very easily go un-noticed!). I'll try pushing the change in v0.6.4 tomorrow morning, but in the event that it still doesn't work, would you be able to repeat the above process that we did for the names CSV file, but this time with the levels endpoint instead? (http://192.168.1.140/info?what=levels) |
|
v0.6.4 is now downloadable! |
|
Just installed and tested. All working as it should!! Many thanks for the perseverance! In case you want it I've attached the levels endpoint file. Hope it helps. I need to create proxy scenes for the rest of my installation but that might need some time put aside to complete! |
|
I am just trying to add some more proxy scenes to eDIN and also configure HA for the lights. Having a few issues! As an example, I have setup HA to switch on/off the kitchen plinth lights by using the entity light.kitchen_plinth_lights. However on activating this light in HA it's actually recalling an eDIN scene "Mood" which is set for the kitchen and switching on 3 different kitchen lights (plinth, downlights & wall lights). I've also setup a proxy scene for the kitchen wall lights at 100% but not sure how long this takes to populate into HA - do I need to refresh anything to get this to register as a new entity in HA? At present there's only one entity for the wall lights showing and this is coming on 100% at 0s fade and not the fade time set for the proxy scene. |
|
Hmm. Will have a look into the kitchen_plinth_lights - should be straightforward to find the issue with the levels file, many thanks for attaching! |
|
Ah, yet another bug in my regex - shall push a fix shortly! Also, as an FYI it's worth nothing that for proxy scenes you only need an "on" scene for each channel, rather than both an "on" and "off" scene (although I suspect that having both comes in useful for other use cases!). |
|
Fix has been pushed in v0.6.5 - please let me know if you have any luck... fingers crossed! |
|
Hi, Thanks for the update. I really hate to bring more bad news, but the new version hasn't picked up the new proxy scenes and has lost the previous ones it had with the lights resorting back to no fade time - sorry! The plinth lights is also still running the Mood scene from eDIN+ and not just switching the plinth lights on/off. I updated the integration and restarted HA so it should have refreshed the entities. I've attached the names file again with the updated proxy scenes I created. The comment about only needing an ON scene is noted but, as you pointed out, I had the off scene created within eDIN for other scenarios. I've also added the new levels file hoping it helps. Just in case this is a problem I've caused, is there a specific naming convention for the proxy scene? I've named them with 100% after the name just to differentiate from other scenes within eDIN+. I'm wondering whether that's causing a problem with the integration not recognising it as a proxy scene? |
|
Hi there, I'm so sorry to have let this slide for so long; have had a pretty hectic month or so. I've had a quick look and the issue is a bit obvious in hindsight - the code will only match for alphanumeric names, so the "%" character is throwing it off. I'll fix the regex when I have a moment, but thought I'd let you know so you've got a way of fixing your end (i.e. substitute or remove the % character from the scene name), if you hadn't already worked it out! |
|
Hi, no apology necessary. Yes removing the % sign has solved the issue for now. Many thanks for that information. These integrations are never easy, especially given the nature of eDIN+! |
After updating to latest version I have the following:
I’ve removed the integration and added again but same problem.
The text was updated successfully, but these errors were encountered: