Discussion of "
Proper support for non-one.zero state devices (blinds,dimmable lights,etc..)" progressed into Mantis bug 0003456: Adding generic "state changed" event would ease support for new various devices to LMCE. Discussion there is about to implement such a change, but there's some more discussion before leaping to the coding keyboard. Let's discuss it here before returning to the Mantis discussion with a more specific plan in mind, for the much more focused discussion that is appropriate to Mantis.
The latest state of play:
I'm bottlenecked for the moment. My first priority has been to install and try out 0710b2, and I've been stuck for a week just doing that. Once I've got it, I need a development environment set up. Then in the context of the existing code I can figure out just which technique is the right one (desired effect and maintainability) to update the code as has been helpfully indicated in this thread. But I'm still getting the app installed, which will be followed by the code installed. However, I think today might be the big day.
In the meantime, we should indeed discuss the impact of this change on the design. C++ is not a language for writing "off the top of your head", unless you're a really inspired expert (I have my moments, but I haven't coded in it fulltime for several years...). C++ demands that you do at least some design upfront, you you'll go down the wrong road, and find later that you can't get where you're going now the way you went. But since there's already quite a bit of design implicit in the existing code, and this change looks more like an increment, it's just probably a matter of an hour or so, not a week, to design the implementation of the change without being reckless.
Meanwhile, this Mantis thread is not the place to discuss anything but what we're actually doing to fix the bug. I've started a new Developers forum topic to discuss the design. I'll chime in (probably later today) when I can roll up my sleeves on this. In the meantime, it is appropriate to talk about whether this incremental feature ("state changed" on floorplan) is best added as already discussed (narrow facility), or would be better addressed with some greater redesign of the system, as it represents crossing some threshold into a greater class of functionality. And whether we should just increment it now for 0710 (most likely) and spend more time (and get more varied advice) on a redesign for a more full-featured facility in the next version (ie. 0804).
I don't want to be a buzzkill, especially when others are offering help and insights while I'm not ready to code this minute. But, as the apparently sole C++ expert in this group right now, I can at least stop us from doing the worst things that a C++ project ever does: rush right into ad hoc coding without planning for the consequences.
Hi,
I agree with your discussion. But if some of main develoepers agreed on the way, what and how to change, I see no apparent obstacles not to do it...
The main thing to be done is to leave hardcoded things in plugins - so current support for currently supported devices will stay. The main change is ability to have additional device data in templates (first one to say "I wanna be on floorplan, serach text to display where I'm pointing to" and second one with proper text to be displayed (latter can be omitted if you point first one to already existing device data - like state for instance...)
I know that probably whole thing of floorplans needs to be redesigned, but that is slow process. Also, probably whole system could be redesigned - but that would be major step back (maybe even needed)....
Currently only few people know LMCE's internals. In my humble opinion we should go with this change, get to know internals better and start discussion on how to organize it better, if possible and needed at all. Right now, I just recognize major bottleneck in ability to interface with various devices and ability to show only few of them on floorplans...
Maybe you don't need everything compiled to make only this change. Maybe we can send diffs to Chris and he will revise them and try... I'm also bad programmer by myself (watchout, there is smaller part of my programming in Motion wrapper
), but these are small changes if I understand right and they won't do much harm, beside increasing amount of code a bit...
I'd suggest if we start exposing parts of code that would need those additions and discuss on those examples... ?
HTH,
regards,
Rob.
