Dev: Added faston messages and manual increment messages

[NickWaterton]

This is to handle faston and manual messages generated by devices. I haven't paid attention to messages sent to devices (as it's similar to instant on).

Devices modified are:

• Switch
• Dimmer
• Remoke
• KeypadLinc (dimmer and switch)

The fast_on state topic is separate from the normal state topic (but they could be made the same), and fast_on is available as a variable in templating.

The fast_on state is published just before the normal state.

This PR also includes manual increment messages. This works the same way as fast_on, but publishes 2 for up, 0 for down and 1 for stop, followed by the normal state topic (except manual dimming of remotes which don't have a state as such). The manual_state topic is separate from the normal and fast_on states. manual is available for templating, but is only really useful in the manual_state topic.

Here is what the output from a dimmer looks like:
dim down, stop
dim up, stop
off (normal)
on (normal)
off (fast)
on (fast)

insteon/office_light/manualstate 0
insteon/office_light/manualstate 1
insteon/office_light/state 41
insteon/office_light/manualstate 2
insteon/office_light/manualstate 1
insteon/office_light/state 78
insteon/office_light/state 0
insteon/office_light/state 100
insteon/office_light/fastonstate { "state" : OFF, "fast_on" : 1 }
insteon/office_light/state 0
insteon/office_light/fastonstate { "state" : ON, "fast_on" : 1 }
insteon/office_light/state 100

This is what a mini remote looks like:

insteon/mini_remote_family_room/fastonstate/1 ON
insteon/mini_remote_family_room/state/1 { "state" : "ON", "faston" : 1 }
insteon/mini_remote_family_room/fastonstate/1 OFF
insteon/mini_remote_family_room/state/1 { "state" : "OFF", "faston" : 1 }
insteon/mini_remote_family_room/fastonstate/1 OFF
insteon/mini_remote_family_room/state/1 { "state" : "OFF", "faston" : 1 }
insteon/mini_remote_family_room/manualstate/1 2
insteon/mini_remote_family_room/manualstate/1 2
insteon/mini_remote_family_room/manualstate/1 1
insteon/mini_remote_family_room/manualstate/1 1
insteon/mini_remote_family_room/manualstate/1 1
insteon/mini_remote_family_room/manualstate/1 1
insteon/mini_remote_family_room/manualstate/1 0
insteon/mini_remote_family_room/manualstate/1 0
insteon/mini_remote_family_room/manualstate/1 1

There are some missed and repeated messages, but I don't think that has anything to do with these changes.

This is what a switch looks like:

insteon/workbench_light/fastonstate OFF
insteon/workbench_light/state OFF
insteon/workbench_light/manualstate 2
insteon/workbench_light/manualstate 1
insteon/workbench_light/state ON
insteon/workbench_light/manualstate 0
insteon/workbench_light/manualstate 1
insteon/workbench_light/state ON
insteon/workbench_light/state OFF
insteon/workbench_light/state ON

This is a 6 button keypadlinc dimmer:

insteon/master_bedroom_kp/fastonstate/1 ON
insteon/master_bedroom_kp/state/1 100
insteon/master_bedroom_kp/fastonstate/1 OFF
insteon/master_bedroom_kp/state/1 0
insteon/master_bedroom_kp/fastonstate/4 ON
insteon/master_bedroom_kp/state/4 ON
insteon/master_bedroom_kp/fastonstate/4 OFF
insteon/master_bedroom_kp/state/4 OFF
insteon/master_bedroom_kp/manualstate/4 2
insteon/master_bedroom_kp/manualstate/4 0
insteon/master_bedroom_kp/manualstate/4 1
insteon/master_bedroom_kp/state/4 ON
insteon/master_bedroom_kp/state/7 ON
insteon/master_bedroom_kp/state/8 ON
insteon/master_bedroom_kp/state/1 0

Not sure why it is reporting buttons 7 and 8 after the manual stop (there is a refresh done here), and it seems to be reporting 8 buttons, even though I only have 6. haven't touched the refresh code though. Might be a bug lurking there?

I included manual state changes, as they are very useful for controlling things like roller blinds and awnings.

[TD22057]

In the future, please do not merge multiple feature changes in one PR. I'd prefer that you open an issue so we can discuss new features and UI choices (in this case for the manual mode), then a PR can be done for that. It's going to take me longer to figure out what I want to do with this. I'm not sure what the use case is for the manual up/down topic so I'm not prepared to merge both of these to get fast on/off.

[NickWaterton]

Manual change is a standard insteon message that was simply being handled as an on/off or not handled at all (and was actually reversed in the code where it was handled). It's useful for things like roller blinds and awnings, where you can use a dimmer or remote to move them up/down and then stop when you release the button.

It is a useful feature. I didn't realize it would be an issue to include with faston/off.

How do you want to proceed? is it a question of whether manual change is worth having, or is it the way it's implemented as a separate topic?

[TD22057]

Couple of things (and these are why it's generally better to talk through the user interface first). Topics with "state" are outputs - they report the state of the system. So "manual_state_topic" would be for reporting the manual state, not controlling it. That, as well as the payload (0,1,2 are not obvious what they mean at all) could be improved so that it's easier to read (maybe -1, 0, +1 for down, stop, up).

Give me a little time - I'm busy with some home remodeling and rewiring right now but I can probably just grab this PR and merge the pieces for each feature separately (and open a new issue to track the manual command discussion). There are also need to be doc updates, release note updates, and pylint/flake8 fixes for style. It will take me a few weeks but I can merge them in.

[TD22057]

I'm confused - after looking more carefully, it looks the manual mode is for reporting that a device is entering manual mode, not commanding it to be in that mode. I can see why being in a mode would be useful (remote control button to start/stop blinds) but not why a separate output topic is desired. The level is already going to be reported so doesn't that already take care of telling you the state of the blind?

[TD22057]

I've merged the faston and manual branches into the dev branch. Docs have been updated and you can find the final API in the sample config.yaml file in the top level directory.