search

icanos / hassio-plejd

Hass.io add-on for Plejd home automation devices
Apache License 2.0
126 stars 37 forks source link

WPH-01 buttons to trigger generic automations in HA #172

Closed faanskit closed 3 years ago

faanskit commented 3 years ago

I would like to use the WPH-01 buttons to trigger automations in HA. Eg. "Leaving the house" ==> Turn off music and all lights. Today I can use the state trigger, but is has a major limitation with WPH-01 registered as a Switch.

If the device is already considered "on", the automation will not perform. Therefore I can only perform a particular scenario once, until the "off" button is pressed. Obviously it would be possible to automate a "off" trigger in the automation, but: I would want to use all four buttons and preferably double-click to trigger different scenarios. (Up to eight is theoretically possible with four distinct buttons).

Maybe this is possible to solve in other ways that using the state trigger. Appreciate tips on how to do that. If not, this is wish for a feature that allows me to do the above.

I have also noted some strange behavior in hassio-plejd when WPH-01 is used (within Plejd) to trigger (Plejd-)scenarios. In this set-up the WPH identities are somehow screwed, My suspiscion is that this mode is not supported by hassio-plejd.

BR, Marcus ps. I only have sporadic access to the system, so there may be delays if logs are needed.

SweVictor commented 3 years ago

I don't have the WPH-01 myself, but as a first step you could make sure that the BLE commands you're looking for are picked up by the addon and MQTT commands are sent (they should be no matter the state).

If so you could either listen to the MQTT command sent by the addon.

If some BLE command is not decoded correctly, please fill in https://github.com/icanos/hassio-plejd/issues/163 what is missing.

Regarding double-click, I'm not sure those actually send a "double-click" command? My understanding is that they don't but rather send a "turn on scene x" command (or whatever you set in the config). Not sure though. Could be the same with single-clicks possibly since the WPH-01 obviously doesn't have its own loads.

faanskit commented 3 years ago

I don't have the WPH-01 myself

I only own one, which is not mounted or used as of today. I could lend you my WPH-01 if you want to play around with it for some time. Let me know, and also how to get in touch with you to get your mailing adress.

If so you could either listen to the MQTT command sent by the addon.

I'll see what I can find next time I am at the system, which should be the coming weekend. Any tips and tricks are appreciated.

Thanks for your efforts!

SweVictor commented 3 years ago

No, that's fine. Basically what you would do to look into what BLE messages you get is setting log level to verbose and save ~3 examples of BLE messages when you press/doubleclick buttons 1/2/3/4. Raw messages are logged and then how they are interpreted.

Regarding reacting to MQTT messages I don't know the details but I'm sure someone has written how to do it in HA somewhere :) Basically you should be able to create an automation using the UI these days if you don't want to code.

faanskit commented 3 years ago

Hey,

Got to the system today, and it behaves quite strange. I'll post some information here, but it cannot really be fully trusted.

The WPH-01 can be used in two modes:

(1) Single click performs on/off (2) Single click performs a scenario In both modes, double-click performs a scenario.

After having had the WPH-01 left button configured to (1) and to control a device, it does not seem to "clear" that setting when changing to mode (2). Therefore the logs taken looks strange.

During the boot, I get the following error in the log:

2021-03-21 12:15:27 ERR [plejd-ble] Failed inspecting /org/bluez/hci0/dev_F2_17_87_3C_CF_90.  Cannot read property 'name' of undefined
TypeError: Cannot read property 'name' of undefined
    at PlejBLEHandler._initDiscoveredPlejdDevice (/plejd/PlejdBLEHandler.js:146:91)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async PlejBLEHandler.onInterfacesAdded (/plejd/PlejdBLEHandler.js:384:9)

I do not know if this relates to the issues I see downstream.

Single klick "off" on left button (that used to be connected to a device):

2021-03-21 12:09:18 VRB [plejd-ble] Raw event received: 00011000162202f80a
2021-03-21 12:09:18 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 34, dim 248
2021-03-21 12:09:18 VRB [plejd-ble] Command 16 unknown. 00011000162202f80a. Device undefined (0)
2021-03-21 12:09:18 VRB [plejd-ble] Raw event received: 19010300c801b082
2021-03-21 12:09:18 VRB [plejd-ble] Decoded: Device 25, cmd c8, state 1, dim 130
2021-03-21 12:09:18 DBG [plejd-ble] Taklampa Matbord (25) got state+dim update. S: 1, D: 130
2021-03-21 12:09:18 VRB [plejd-mqtt] Updating state for Taklampa Matbord: 1, dim: 130
2021-03-21 12:09:18 VRB [plejd-ble] Raw event received: 230110009700
2021-03-21 12:09:18 VRB [plejd-ble] Decoded: Device 35, cmd 97, state 0, dim 0
2021-03-21 12:09:18 DBG [plejd-ble] Entre left (35) got state update. S: 0
2021-03-21 12:09:18 VRB [plejd-mqtt] Updating state for Entre left: 0
2021-03-21 12:09:18 VRB [plejd-mqtt] Sent mqtt state command for light, Taklampa Matbord (25). 
2021-03-21 12:09:18 VRB [plejd-mqtt] Sent mqtt availability command for light, Taklampa Matbord (25). online
2021-03-21 12:09:18 VRB [plejd-mqtt] Sent mqtt state command for switch, Entre left (35). 
2021-03-21 12:09:18 VRB [plejd-mqtt] Sent mqtt availability command for switch, Entre left (35). online

As you can see, there are both unknown commands as well as undefined device. And, it still performs the action towards device (25) that "should" have been removed.

Single klick "off" on right button (that have not been connected to any scenarios or devices)

2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 010110001b0838576001
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 1, cmd 1b, state 8, dim 87
2021-03-21 12:11:45 DBG [plejd-ble] Plejd clock time update Sun Mar 21 2021 12:11:52 GMT+0100 (Central European Standard Time), diff 7 seconds
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 010110001b0838576001
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 1, cmd 1b, state 8, dim 87
2021-03-21 12:11:45 DBG [plejd-ble] Plejd clock time update Sun Mar 21 2021 12:11:52 GMT+0100 (Central European Standard Time), diff 7 seconds
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 0001100015
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 0, cmd 15, state 0, dim 0
2021-03-21 12:11:45 VRB [plejd-ble] Command 15 unknown. 0001100015. Device undefined (0)
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 0001100015
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 0, cmd 15, state 0, dim 0
2021-03-21 12:11:45 VRB [plejd-ble] Command 15 unknown. 0001100015. Device undefined (0)
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 00011000162203f50a
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 34, dim 245
2021-03-21 12:11:45 VRB [plejd-ble] Command 16 unknown. 00011000162203f50a. Device undefined (0)
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 00011000162203f50a
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 34, dim 245
2021-03-21 12:11:45 VRB [plejd-ble] Command 16 unknown. 00011000162203f50a. Device undefined (0)
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 0201100021ff
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 2, cmd 21, state 255, dim 0
2021-03-21 12:11:45 DBG [plejd-ble] undefined (255) scene triggered (device id 2). Name can be misleading if there is a device with the same numeric id.
2021-03-21 12:11:45 VRB [plejd-mqtt] Scene triggered: 255
2021-03-21 12:11:45 VRB [plejd-ble] Raw event received: 0201100021ff
2021-03-21 12:11:45 VRB [plejd-ble] Decoded: Device 2, cmd 21, state 255, dim 0
2021-03-21 12:11:45 DBG [plejd-ble] undefined (255) scene triggered (device id 2). Name can be misleading if there is a device with the same numeric id.
2021-03-21 12:11:45 VRB [plejd-mqtt] Scene triggered: 255

I have now removed the WPH-01 from my system and will set-up a new system at my second HA installation (at home). But today Plejd seems to have issues with the service.

When I have this clean system set up, I will take more logs from a "clean" device.

Can you please guide how to fetch the logs. Due to lack of competence, I now use the "Log" section in HA-PLED, but it quickly overflows. Tried to use log viewer, but I lack some base knowledge.

Food for thought: Shouldn't the WPH-01 be registered as a sensor instead? I find it odd to have it configured as a switch.

faanskit commented 3 years ago

After some struggle, I finally have a fresh hassio-plejd installation. Possibly corrupt.

Installed Plejd twice, with the same result. A message indication installation failure, but after a reboot it looks to be installed anyway. No useful information in the system logs.

The Plejd system is super simple. Possibly too simple, having only the WPH-01. It cycles this message:

2021-03-22 11:07:48 INF [plejd-main] Bluetooth reconnecting...
2021-03-22 11:07:48 INF [plejd-ble] Reconnecting BLE...
2021-03-22 11:07:48 INF [plejd-ble] init()
2021-03-22 11:07:48 VRB [plejd-ble] dbus-next connected
2021-03-22 11:07:48 VRB [plejd-ble] Managed paths[
  "/org/bluez",
  "/org/bluez/hci0"
]
2021-03-22 11:07:48 DBG [plejd-ble] Found BLE interface 'org.bluez.Adapter1' at /org/bluez/hci0
2021-03-22 11:07:49 VRB [plejd-ble] Iterating 2 BLE managedObjects looking for org.bluez.Device1
2021-03-22 11:07:49 VRB [plejd-ble] All active BLE device connections cleaned up.
2021-03-22 11:07:49 VRB [plejd-ble] Got adapter undefined
2021-03-22 11:07:49 VRB [plejd-ble] Setting up interfacesAdded subscription and discovery filter
2021-03-22 11:07:49 VRB [plejd-ble] Starting BLE discovery... This can take up to 180 seconds.
2021-03-22 11:07:49 VRB [plejd-ble] Started BLE discovery
2021-03-22 11:07:49 INF [plejd-ble] BLE init done, waiting for devices.
2021-03-22 11:07:51 ERR [plejd-ble] Discovery timeout elapsed, no devices found. Starting reconnect loop...
2021-03-22 11:07:51 DBG [plejd-ble] Starting reconnect loop due to Discovery timeout elapsed
2021-03-22 11:07:51 VRB [plejd-ble] startReconnectPeriodicallyLoop

Efter a few attempts it throws this:

2021-03-22 11:08:04 INF [plejd-ble] Reconnecting BLE...
2021-03-22 11:08:04 INF [plejd-ble] init()
2021-03-22 11:08:04 VRB [plejd-ble] dbus-next error event: The maximum number of active connections for UID 0 has been reached
(node:301) UnhandledPromiseRejectionWarning: Error: DBusError: The maximum number of active connections for UID 0 has been reached
    at /plejd/node_modules/dbus-next/lib/bus.js:176:15
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:301) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)

But, I think the problem is related to WPH-01 being a battery driven device and likely not always responding. Pushing some buttons on the WPH-01 seems to keep it awake for some time at least.

Captured this log; showing at least a button press, and some follow up issues.

2021-03-22 11:15:15 VRB [plejd-ble] Raw event received: 00011000160b037d0a
2021-03-22 11:15:15 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 125
2021-03-22 11:15:15 VRB [plejd-ble] Command 16 unknown. 00011000160b037d0a. Device undefined (0)
2021-03-22 11:15:15 VRB [plejd-ble] Raw event received: 00011000160b037d0a
2021-03-22 11:15:15 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 125
2021-03-22 11:15:15 VRB [plejd-ble] Command 16 unknown. 00011000160b037d0a. Device undefined (0)
2021-03-22 11:15:20 VRB [plejd-ble] Error pinging Plejd, calling onWriteFailed... Operation failed with ATT error: 0x0e
2021-03-22 11:15:20 DBG [plejd-ble] onWriteFailed #1 in a row. Operation failed with ATT error: 0x0e
DBusError: Operation failed with ATT error: 0x0e
    at _methodReturnHandlers.<computed> (/plejd/node_modules/dbus-next/lib/bus.js:343:27)
    at handleMessage (/plejd/node_modules/dbus-next/lib/bus.js:101:11)
    at EventEmitter.<anonymous> (/plejd/node_modules/dbus-next/lib/bus.js:151:9)
    at EventEmitter.emit (events.js:314:20)
    at /plejd/node_modules/dbus-next/lib/connection.js:116:14
    at Socket.<anonymous> (/plejd/node_modules/dbus-next/lib/message.js:63:9)
    at Socket.emit (events.js:314:20)
    at emitReadable_ (_stream_readable.js:557:12)
    at processTicksAndRejections (internal/process/task_queues.js:83:21)
2021-03-22 11:15:20 VRB [plejd-ble] Error message: Operation failed with ATT error: 0x0e
2021-03-22 11:15:20 ERR [plejd-ble] 'Unlikely error' (0x0e) writing to Plejd. Will retry. Operation failed with ATT error: 0x0e
DBusError: Operation failed with ATT error: 0x0e
    at _methodReturnHandlers.<computed> (/plejd/node_modules/dbus-next/lib/bus.js:343:27)
    at handleMessage (/plejd/node_modules/dbus-next/lib/bus.js:101:11)
    at EventEmitter.<anonymous> (/plejd/node_modules/dbus-next/lib/bus.js:151:9)
    at EventEmitter.emit (events.js:314:20)
    at /plejd/node_modules/dbus-next/lib/connection.js:116:14
    at Socket.<anonymous> (/plejd/node_modules/dbus-next/lib/message.js:63:9)
    at Socket.emit (events.js:314:20)
    at emitReadable_ (_stream_readable.js:557:12)
    at processTicksAndRejections (internal/process/task_queues.js:83:21)
2021-03-22 11:15:20 VRB [plejd-ble] Made it false || false
2021-03-22 11:15:20 VRB [plejd-ble] Error pinging Plejd, calling onWriteFailed... Operation failed with ATT error: 0x0e

To make this useful, I think I need to add a regular device to my system. WPH-01 only is not really working out. Hopefully I can get the one I have with a blown fuse up and running. It was at least communicating at the mesh before I replaced it. Else I guess have to transform my Nexa with Plejd sooner than later...

Or...it may also be that the failed installation is causing these issues, but I do not think so.

Will report back...

SweVictor commented 3 years ago

Interesting - there seem to be two unknown commands (15 and 16) being emitted, anyone knows more about what they "say"? Also the WPH-01 seems to emit double BLE commands, presumably one for the click and one for "what should happen"...

Could you please also send the id of the WPH-01 (numeric 0-255), and/or any other identifying information? To get more info we need to try to figure out what the data fields are for for commands 15 and 16.

Regarding your other issues I would guess that the WPH-01 being a battery powered device will power down so it's probably not optimal for the addon (or the app) to connect to. But it obviously works somewhat...

The "maximum number of connections for UID 0" I got as well when connection was reconnected a lot of times (persisted even after addon restart). I wrote about it in some other issue, but only solved it after removing the reconnects by moving the adapter closer to the Plejd device. Some internals in the dbus implementation I think, but I don't know how to continue.

Regarding logs, please refer to the logs section of the readme.

SweVictor commented 3 years ago

Btw - there is a v0.7.0-dev in the dev branch if you want to try the latest in BLE connection management.

faanskit commented 3 years ago

At this point I cannot trust the logs of the system to identify behavior. I'll have to get the (broken) REL-02 up and running and a stable system, then I'll start logging properly.

At this point, I cannot even find the Id of the device in a simple way. Also, I've seen logs where command 15/16 are repeated 6-7 times consecutively.

So, let me get back when I have the system stable again.

faanskit commented 3 years ago

Ok, now I have a clean install.

One single CTL-01 (name: Relä) and one WPH-01(name:Kontor). The WPH-01 is completely untouched. Buttons are not assigned to anything.

In Home Assistant, two devices appear: Relä, as Light Kontor right, as Switch

NOTE: There is no Kontor left, which one could expect.

Logs set Verbose.

During BLE discovery

2021-03-22 21:13:04 VRB [plejd-ble] Starting BLE discovery... This can take up to 180 seconds.
2021-03-22 21:13:04 VRB [plejd-main] connected to mqtt.
2021-03-22 21:13:04 DBG [plejd-mqtt] Sending discovery of 2 device(s).
2021-03-22 21:13:04 DBG [plejd-mqtt] Sending discovery for Relä
2021-03-22 21:13:04 INF [plejd-mqtt] Discovered light (CTR-01) named Relä with PID 12.
2021-03-22 21:13:04 DBG [plejd-mqtt] Sending discovery for Kontor right
2021-03-22 21:13:04 INF [plejd-mqtt] Discovered switch (WPH-01) named Kontor right with PID 255.

PID 255 looks suspicious. 0xFF looks like an end-of-something.

Left Button On - Single click

2021-03-22 21:13:24 VRB [plejd-ble] Raw event received: 00011000160b00c70a
2021-03-22 21:13:24 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 199
2021-03-22 21:13:24 VRB [plejd-ble] Command 16 unknown. 00011000160b00c70a. Device undefined (0)

Left Button Off - Single click

2021-03-22 21:13:26 VRB [plejd-ble] Raw event received: 00011000160b02c70a
2021-03-22 21:13:26 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 199
2021-03-22 21:13:26 VRB [plejd-ble] Command 16 unknown. 00011000160b02c70a. Device undefined (0)

Right Button On - Single click

2021-03-22 21:13:29 VRB [plejd-ble] Raw event received: 00011000160b01c70a
2021-03-22 21:13:29 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 199
2021-03-22 21:13:29 VRB [plejd-ble] Command 16 unknown. 00011000160b01c70a. Device undefined (0)

Right Button Off - Single click

2021-03-22 21:13:31 VRB [plejd-ble] Raw event received: 00011000160b03c70a
2021-03-22 21:13:31 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 199
2021-03-22 21:13:31 VRB [plejd-ble] Command 16 unknown. 00011000160b03c70a. Device undefined (0)

Left Button On - Double click

2021-03-22 21:28:43 VRB [plejd-ble] Raw event received: 00011000160b00c70a
2021-03-22 21:28:43 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 199
2021-03-22 21:28:43 VRB [plejd-ble] Command 16 unknown. 00011000160b00c70a. Device undefined (0)
2021-03-22 21:28:43 VRB [plejd-ble] Raw event received: 00011000160b00c40a
2021-03-22 21:28:43 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:43 VRB [plejd-ble] Command 16 unknown. 00011000160b00c40a. Device undefined (0)

Left Button Off - Double click

2021-03-22 21:28:46 VRB [plejd-ble] Raw event received: 00011000160b02c40a
2021-03-22 21:28:46 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:46 VRB [plejd-ble] Command 16 unknown. 00011000160b02c40a. Device undefined (0)
2021-03-22 21:28:46 VRB [plejd-ble] Raw event received: 00011000160b02c40a
2021-03-22 21:28:46 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:46 VRB [plejd-ble] Command 16 unknown. 00011000160b02c40a. Device undefined (0)

Right Button On - Double click

2021-03-22 21:28:48 VRB [plejd-ble] Raw event received: 00011000160b01c40a
2021-03-22 21:28:48 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:48 VRB [plejd-ble] Command 16 unknown. 00011000160b01c40a. Device undefined (0)
2021-03-22 21:28:49 VRB [plejd-ble] Raw event received: 00011000160b01c40a
2021-03-22 21:28:49 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:49 VRB [plejd-ble] Command 16 unknown. 00011000160b01c40a. Device undefined (0)

Right Button Off - Double click

2021-03-22 21:28:50 VRB [plejd-ble] Raw event received: 00011000160b03c40a
2021-03-22 21:28:50 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:50 VRB [plejd-ble] Command 16 unknown. 00011000160b03c40a. Device undefined (0)
2021-03-22 21:28:50 VRB [plejd-ble] Raw event received: 00011000160b03c40a
2021-03-22 21:28:50 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-22 21:28:50 VRB [plejd-ble] Command 16 unknown. 00011000160b03c40a. Device undefined (0)

My interpretation: 00011000160b00c70a => 00 is left on clicked 00011000160b02c70a => 02 is left off clicked 00011000160b01c70a => 01 is right on clicked 00011000160b03c70a => 03 is right off clicked

Double-click are just two consecutive events. If I do a triple click, I just get three events,

Let me know if you want some other tests or loglevels before I connect the buttons to the CTL-01 and Scenes. From experience, it will never be "clean" again.

The full verbose log: log.txt

BR, Marcus

SweVictor commented 3 years ago

Interesting. You're probably right in that this "raw" state will not return after configuring things.

What looks a bit strange is as you say - no left button. Also the right button has id = 255 (max value, looks strange). My hunch is that unassigned outputs are assigned to 255 (0xff) and that the left button 0xff is overwritten by the right button 0xff. I have been looking at how we parse devices for a while, we actually only parse "outputs" (rather than inputs/buttons) so it probably makes sense.

If you can, it would be nice to look at the API response. You can either get it manually or just turn on silly logging and it should show up in the log. You might want to scrub any sensitive details before posting though :)

Specfically I'm hoping we can correlate 0xc7 or 0x0a to the device in question. My guess is that the button has id 0xc7 and that then as you say the four buttons are named 00 => 03.

Finally - what happens if you press and hold the buttons? I suppose you can dim stuff normally, but what happens in the "raw" state?

faanskit commented 3 years ago

Finally - what happens if you press and hold the buttons? I suppose you can dim stuff normally, but what happens in the "raw" state?

I tested that yesterday as well. Strangely nothing. Only a single RAW event was sent. But, I think that behavior can change when assigning the button to a device.

If you can, it would be nice to look at the API response. You can either get it manually or just turn on silly logging and it should show up in the log. You might want to scrub any sensitive details before posting though :)

I'll post that later. Did yet another clean install hoping that "Left" would re-appear when setting up the system again, while capturing that initial start in a log. But I had log set to debug only, so information was not really useful.

I suspect that the button has some kind of meta state since it has different behaviors. Eg.

LEFT_NO_ASSIGNMENT; RIGHT_NO_ASSIGNMENT
LEFT_NO_ASSIGNMENT; RIGHT_ASSIGNED_TO_CLICK
LEFT_NO_ASSIGNMENT; RIGHT_ASSIGNED_TO_SCENE
LEFT_ASSIGNED_TO_CLICK; RIGHT_NO_ASSIGNMENT
LEFT_ASSIGNED_TO_CLICK;RIGHT_ASSIGNED_TO_CLICK
LEFT_ASSIGNED_TO_CLICK;RIGHT_ASSIGNED_TO_SCENE
LEFT_ASSIGNED_TO_SCENE; RIGHT_NO_ASSIGNMENT
LEFT_ASSIGNED_TO_SCENE;RIGHT_ASSIGNED_TO_CLICK
LEFT_ASSIGNED_TO_SCENE;RIGHT_ASSIGNED_TO_SCENE

And, I think the ID will change when I assign left/right to different behavior.

So, a bit more logging of different variants before anything can be concluded.

faanskit commented 3 years ago

I'll post that later.

Here comes the log. Hopefully scrubbed. silly_log.txt

Take note that: (1) the ID is set to 255, (2) there are four identifiers 

  "inputAddress": {
    "F7EFCACF2614": {
      "0": 255,
      "1": 255,
      "2": 255,
      "3": 255
    },

I also note that the DIM and the CTR has similar structure, both having two buttons. Likely we can catch these as well.

    "C061998B0B5F": {
      "0": 12,
      "1": 12
    },
    "C12D372125FD": {
      "0": 13,
      "1": 13
    }

Another reflection is found here:

  "deviceAddress": {
    "F7EFCACF2614": 11,
    "C061998B0B5F": 12,
    "C12D372125FD": 13
  },

There is a correlation between 12/13 and the adress. But 11 does not match 255. But...11 can be found in the raw events when pressing the button: 2021-03-23 10:17:34 VRB [plejd-ble] Raw event received: 00011000160b00b90a Question is if it is the first or the second 0x0b. I need yet another WPH-01 :-) Maybe I can trace raw events from the DIM/CTR to get an understanding of that. Need to connect a switch to the devices tonigt.

Would be nice if we could send these to HA as device_triggers. I think that is how Hue Smart Switches are sent. In this way, a lot of interresting stuff could be triggered from any Plejd device in HA.

faanskit commented 3 years ago

My hunch is that unassigned outputs are assigned to 255 (0xff) and that the left button 0xff is overwritten by the right button 0xff.

I think your hunch is correct. From the other system I have seen the Id 255 appearing from time to time, depending on configuration of the WPH.

Will take logs in various configurations to confirm this.

SweVictor commented 3 years ago

I think we're on the right track here. And the 0x0b is most certainly state. Scenes are triggered this same way (scene id is what we parse as "state"). So based on the logs I think we can safely assume state is the input address

2021-03-23 10:17:36 VRB [plejd-ble] Raw event received: 00011000160b02b90a
2021-03-23 10:17:36 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 185
2021-03-23 10:17:36 VRB [plejd-ble] Command 16 unknown. 00011000160b02b90a. Device undefined (0)

So the 0b02 part above is presumably "device 11 (0x0b), button 2 (left off)"

faanskit commented 3 years ago

I can trace raw events from the DIM/CTR to get an understanding of that.

Sadly, no relevant information. No raw events from CTR-01 indicating "click", even though the switches are not configured in the app.

SweVictor commented 3 years ago

Sadly, no relevant information. No raw events from CTR-01 indicating "click", even though the switches are not configured in the app.

Yeah, I think that's a known "feature" - normal devices don't seem to send much if no load is connected which I suppose is why the addon works the way it does (works with the outputs only).

I think you normally should get state updates for the "own" load (normally the output changes on click), but you might not get this with only one device I suppose, don't know really.

... On the other hand, if you set WPH-01 to control the load of CTR-01 I suppose WPH-01 must know the state of the output? Very confusing all this :)

Aaanyway - bit the bullet and released the long pending 0.7.0. Might improve/change BLE behavior, should not change functional behavior.

faanskit commented 3 years ago

New logs, now with a configured system. silly_log_assigned.txt

PLEJD CONFIGURATION
===================
CTR-01, 1x, id 12 (0x0c)
DIM-01, 1x, id 13  (0x0d)
WPH-01, 1x, id 11 (0x0b)

WPH-01 CONFIGURATION
====================
Left On         ==> CTR-01, ON
Left Off        ==> CTR-01, OFF
Left On Double  ==> Scenario LeftOn     ==> CTR-01, ON
Left On Double  ==> Scenario LeftOff    ==> CTR-01, OFF

Right On        ==> Scenario RightOn     ==>DIM-01, ON 100%
Right Off       ==> Scenario RightOff    ==>DIM-01, OFF
Right On Double ==> Scenario LeftOn     ==> CTR-01, ON
Right On Double ==> Scenario LeftOff    ==> CTR-01, OFF

What looks a bit strange is as you say - no left button. Also the right button has id = 255 (max value, looks strange). My hunch is that unassigned outputs are assigned to 255 (0xff) and that the left button 0xff is overwritten by the right button 0xff. I have been looking at how we parse devices for a while, we actually only parse "outputs" (rather than inputs/buttons) so it probably makes sense.

The system now have both buttons assigned, and showing up in the HA Ui. Now the WPH-01 is assigned two identifiers, 11 and 255. From previous post, remember we assumed it to be 11. So 255 is stull in use.

2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (WPH-01) named Brytare left with PID 11.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered light (CTR-01) named Relä with PID 12.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered light (DIM-01) named Dimmer with PID 13.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (WPH-01) named Brytare right with PID 255.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (Scene) named LeftOn with PID 1.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (Scene) named LeftOff with PID 2.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (Scene) named RightOn with PID 3.
2021-03-23 15:48:17 INF [plejd-mqtt] Discovered switch (Scene) named RightOff with PID 4.

Question what happens with a second WPH? A wild guess (hypothesis) that they assign them from the tail. Ie. 255->254->... I need a second WPH :-)

This is important information as it tells what behavior the button has. Perform a scene, or perform act as On/Off for a device.

  "inputSettings": [
    {
      "deviceId": "F7EFCACF2614",
      "siteId": "---scrubbed---",
      "input": 0,
      "buttonType": "DirectionUp",
    {
      "deviceId": "F7EFCACF2614",
      "siteId": "---scrubbed---",
      "input": 1,
      "buttonType": "Scene",

Also, which scene are performed are quite clear:

      "singleClick": "54a94e2e-8ae0-4349-b113-748397709807",
      "doubleClick": "ed815a49-5f12-4def-bb90-edc90e5c2603",

I think this is also important since the WPH-01 can either be used as a single or double button: "doubleSidedDirectionButton": true,

Input address now looks like this:

  "inputAddress": {
    "F7EFCACF2614": {
      "0": 11,
      "1": 255,
      "2": 11,
      "3": 255
    },

I have captured "LEFT ON, LEFT OFF, RIGHT ON, RIGHT OFF, LEFT ON DOUBLE, LEFT OFF DOUBLE, RIGHT ON DOUBLE and RIGHT OFF DOUBLE"

Still, the RAW event is not providing a clear identifier on position [0]

LEFT ON
======
2021-03-23 15:27:43 VRB [plejd-ble] Raw event received: 00011000160b00c40a
2021-03-23 15:27:43 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-23 15:27:43 VRB [plejd-ble] Command 16 unknown. 00011000160b00c40a. Device undefined (0)

LEFT OFF
======
2021-03-23 15:31:14 VRB [plejd-ble] Raw event received: 00011000160b02c40a
2021-03-23 15:31:14 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-23 15:31:14 VRB [plejd-ble] Command 16 unknown. 00011000160b02c40a. Device undefined (0)

RIGHT ON
======
2021-03-23 15:42:32 VRB [plejd-ble] Raw event received: 00011000160b01c40a
2021-03-23 15:42:32 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-23 15:42:32 VRB [plejd-ble] Command 16 unknown. 00011000160b01c40a. Device undefined (0)

RIGHT OFF
======
2021-03-23 15:43:03 VRB [plejd-ble] Raw event received: 00011000160b03c40a
2021-03-23 15:43:03 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-23 15:43:03 VRB [plejd-ble] Command 16 unknown. 00011000160b03c40a. Device undefined (0)

Not sure what to make out of this. But, the WPH-.01 code sure need some stabilization. And, I would want the button events to be transported to HA as device_triggers.

What do you make out of all this?

/Marcus

faanskit commented 3 years ago

A first proposed change to make the WPH-01 code more stable. Not a js coder, and not tested. Will attempt to set-up a development environment later. Never done that on HA before....

In order to register the device, also when not assigned to devices or scenarios: Replace this line: PlejdApi.js Line 308: const first = inputs[0]; ==> const first = deviceNum; Or simply remove line 313.

This will undo the overwriting in the following scenario, allowing both left and right button appear properly in the HA Ui.

    "F7EFCACF2614": {
      "0": 255,
      "1": 255,
      "2": 255,
      "3": 255
    },
SweVictor commented 3 years ago

Very nice writeup!

So - my take below. Refer to #163 for decoding. The first three bytes

LEFT UP - set to set to ON id 12 (0x0c)

Raw event received: 00011000160b00c40a - received 3 times

Raw event received: 0c010300c800ffff - received 3 times, the actual command sent to turn on the CTR-01. Decoded correctly already:

LEFT DOWN - set to set to OFF id 12 (0x0c)

Raw event received: 00011000160b02c40a received 5 times

Raw event received: 0b01100000 received 5 times

Raw event received: 0b0110009700 - received 5 times, decoded correctly (?)

Raw event received: 0c0110009800ffff00 - received 5 times, decoded correctly

RIGHT UP set to trigger scene RightOn

Raw event received: 00011000160b01c40a (received only once)

Raw event received: 020110002103 - received only once, decoded correctly

Raw event received: 0d0110009801ffff00

RIGHT DOWN set to trigger scene RightOff

Raw event received: 00011000160b03c40a received only once

Raw event received: 020110002104 - received once, decoded correctly

Raw event received: 0d0110009800ffff00

LEFT UP DOUBLE set to trigger scene LeftOn

Raw event received: 00011000160b00c40a - received 2 times

Raw event received: 020110002101 - received 2 times, decoded correctly

No actual device commands sent out, maybe intentional

LEFT DOWN DOUBLE set to trigger scene LeftOff

Raw event received: 00011000160b02c00a received 2 times

Raw event received: 0b01100000 (2 times)

Raw event received: 0c010300c801ffff (2 times)

Raw event received: 020110002102 (2 times, decoded correctly)

Raw event received: 0c0110009800ffff00 (2 times)

RIGHT UP DOUBLE set to trigger scene LeftOn

Raw event received: 00011000160b01c70a (1 time)

Raw event received: 020110002101 (1 time, decoded correctly)

Raw event received: 0c0110009801ffff00 - 1 time, decoded correctly

RIGHT DOWN DOUBLE set to trigger scene LeftOff

Raw event received: 00011000160b03c40a (1 time)

Raw event received: 020110002102, 1 time, decoded correctly

Raw event received: 0c0110009800ffff00

SweVictor commented 3 years ago

A first proposed change to make the WPH-01 code more stable. ... This will undo the overwriting in the following scenario, allowing both left and right button appear properly in the HA Ui.

   "F7EFCACF2614": {
     "0": 255,
     "1": 255,
     "2": 255,
     "3": 255
   },

Personally I don't think this is the right way to go. I rather think 255 is a placeholder for "unassigned". I do however think your original though ("Shouldn't the WPH-01 be registered as a sensor instead? I find it odd to have it configured as a switch.") was on-point.

So - looking at your post and my previous reply - I think WPH-01 buttons should be created as sensors, state change triggered on command 0016. The current code should probably exclude device 255, but otherwise I think it looks quite ok.

faanskit commented 3 years ago

So - looking at your post and my previous reply - I think WPH-01 buttons should be created as sensors, state change triggered on command 0016. The current code should probably exclude device 255, but otherwise I think it looks quite ok.

Agree. Suggest to sneak peak at Xiami sensors: https://www.home-assistant.io/integrations/binary_sensor.xiaomi_aqara/

Eg. State: off(always) Event: plejd Event key: click_type Event values: single

It seems double click is not possible to catch (or implement). Double click is always connected to a scenario in the Plejd app, and from the looks of the logs - it is the WPH-01 that spawns off the scenario.

faanskit commented 3 years ago

Double click is always connected to a scenario in the Plejd app, and from the looks of the logs - it is the WPH-01 that spawns off the scenario.

This leads to a relevant conclusion: The only way to capture WPH-01 double-click is to implement it as a workaround using Plejd Scenarios, These are already captured as a switches in Home Assistant in hassio-plejd.

For this to work, a "dummy" Plejd device will be required. A recommendation for someone starting with Plejd now is to change one DIM-01 to a DIM-02, or a CTR-01 to a REL-02 and leave the second load unused. It can be used for dummy scenarios in Plejd.

SweVictor commented 3 years ago

Double click is always connected to a scenario in the Plejd app, and from the looks of the logs - it is the WPH-01 that spawns off the scenario.

The only way to capture WPH-01 double-click is to implement it as a workaround using Plejd Scenarios, These are already captured as a switches in Home Assistant in hassio-plejd.

Hmm... For the WPH-01 we actually get every click, right? So double-click logic could be implemented by this addon or HA (which is better)? For other devices I unfortunately don't think they send any kind of BLE command on double-click.

faanskit commented 3 years ago

Hmm... For the WPH-01 we actually get every click, right? So double-click logic could be implemented by this addon or HA (which is better)? For other devices I unfortunately don't think they send any kind of BLE command on double-click.

That is the weird thing. When I trace double-click, it really doesn't provide that level of details. Especially when the device is configured.

This is the complete log for a double-click:

RIGHT OFF DOUBLE
================
2021-03-23 15:44:17 SLY [plejd-ble] Dim: c4, full precision: c403
2021-03-23 15:44:17 VRB [plejd-ble] Raw event received: 00011000160b03c40a
2021-03-23 15:44:17 VRB [plejd-ble] Decoded: Device 0, cmd 16, state 11, dim 196
2021-03-23 15:44:17 VRB [plejd-ble] Command 16 unknown. 00011000160b03c40a. Device undefined (0)
2021-03-23 15:44:17 SLY [plejd-ble] Dim: 0, full precision: 0
2021-03-23 15:44:17 VRB [plejd-ble] Raw event received: 020110002102
2021-03-23 15:44:17 VRB [plejd-ble] Decoded: Device 2, cmd 21, state 2, dim 0
2021-03-23 15:44:17 DBG [plejd-ble] LeftOff (2) scene triggered (device id 2). Name can be misleading if there is a device with the same numeric id.
2021-03-23 15:44:17 VRB [plejd-mqtt] Scene triggered: 2
2021-03-23 15:44:19 SLY [plejd-ble] Dim: ff, full precision: ffff
2021-03-23 15:44:19 VRB [plejd-ble] Raw event received: 0c0110009800ffff00
2021-03-23 15:44:19 VRB [plejd-ble] Decoded: Device 12, cmd 98, state 0, dim 255
2021-03-23 15:44:19 DBG [plejd-ble] Relä (12) got state+dim update. S: 0, D: 255
2021-03-23 15:44:19 VRB [plejd-mqtt] Updating state for Relä: 0, dim: 255
2021-03-23 15:44:19 SLY [plejd-ble] All states: {
  "12": {
    "state": 0,
    "dim": 255
  },
  "13": {
    "state": 0,
    "dim": 255
  }
}
2021-03-23 15:44:19 VRB [plejd-mqtt] Sent mqtt state command for light, Relä (12).
2021-03-23 15:44:19 VRB [plejd-mqtt] Sent mqtt availability command for light, Relä (12). online

In this example, only a single 00011000160b03c40a was sent, followed by a 020110002102.

So, it behaves differently if a scenario is attached to it or not. Another thing I can't get my hands on is that I often get consecutive repeated messages (often 3), and I can't help thinking that there is a correlation between number of devices and repetitions read. That may be how the mesh is implemented - as a simple repeater. And; since you suspect 00 is broadcast; it makes sense that everyone repeats.

Or, it is sending several messages to ensure they at least one of them are received. But there is nothing that indicates interleaving sequencing. Ie. the mesh looks simple-stupid.

But hey; I only look at a few signals - i have no clue how it is implemented.

Nevertheless: Since we cannot know how many messages are received for a single press, we might not be able to even identify if it is a double-press or not.

/Marcus

SweVictor commented 3 years ago

Yes, you're right. Configuring scenes for both click and double-click completely removes the repetition of commands it seems. Having device + command or unassigned it works very differently.

Best ways is probably as you suggest to suggest people create "dummy scenes" which could control the same device's output all of them.

Does dimming (long pressing) work now for the DIM-01 (if you set it's load as dimmable)? But then we're back to classic "controlling the output" which this addon already supports...

faanskit commented 3 years ago

Does dimming (long pressing) work now for the DIM-01 (if you set it's load as dimmable)? But then we're back to classic "controlling the output" which this addon already supports...

Yes, and I captured that in the attached log. verbose_log_dim_up_down.txt

It contains:

PLEJD CONFIGURATION
===================
CTR-01, 1x
DIM-01, 1x
WPH-01, 1x

WPH-01 CONFIGURATION
====================
Left On         ==> CTR-01, ON
Left Off        ==> CTR-01, OFF
Left On Double  ==> Scenario LeftOn     ==> CTR-01, ON
Left On Double  ==> Scenario LeftOff    ==> CTR-01, OFF

Right On        ==> DIM-01, ON
Right Off       ==> DIM-01, OFF
Right On Double ==> Scenario LeftOn     ==> CTR-01, ON
Right On Double ==> Scenario LeftOff    ==> CTR-01, OFF

Use case 1: Short press WPH-01 ON button, to turn on DIM-01 Use case 2: Long press WPH-01 ON button, to dim up DIM-01 Use case 3: Long press WPH-01 OFF button, to dim down DIM-01 Use case 4: Short press WPH-01 OFF button, to turn off DIM-01 Bonus: The log captured when I changed WPH-01 from driving scenarios on single click to drive DIM-01

What you will notice is one single broadcast from the WPH-01 followed by a series of targeted messages to DIM-01. It appears as the WPH-01 has knowledge on how to perform changes on the DIM-01 and are not blindly broadcasting when long pressed. Kind of wierd to load that logic into the button. I would have made it less intelligent and saved both hardware and software costs. If they launch an new product what would benefit from long-press, do they have to upgrade the WPH-01?

I think we can safely assume that WRT-01 behaves exactly like WPH-01.

/Marcus

faanskit commented 3 years ago

One more thing to note:

2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (WPH-01) named Brytare left with PID 11.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered light (CTR-01) named Relä with PID 12.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered light (DIM-01) named Dimmer with PID 13.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (WPH-01) named Brytare right with PID 14.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (Scene) named LeftOn with PID 1.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (Scene) named LeftOff with PID 2.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (Scene) named RightOn with PID 3.
2021-03-24 18:27:12 INF [plejd-mqtt] Discovered switch (Scene) named RightOff with PID 4.

WPH-01 now has id 11 and 14; 255 seems to be connected to scenario assignment, or as you said - undefined. I's say - unassigned.

faanskit commented 3 years ago

WPH-01 now has id 11 and 14; 255 seems to be connected to scenario assignment, or as you said - undefined. I's say - unassigned.

And this leads to a Ui related bug: reassined_wph_2

reassined_wph

I have now two switches (switch.brytare_right, switch.brytare_right_2), both named the same. I've seen this problem in my other HA installation when playing with the WPH. Only way to get rid of it is to re-install MQTT and Plejd :-/

/Marcus

faanskit commented 3 years ago

WPH-01 now has id 11 and 14; 255 seems to be connected to scenario assignment, or as you said - undefined. I's say - unassigned.

This comment needed some more data I realized, so a fresh start with Silly logging attached: silly_startup_in_new_config.txt

The noteworthy change is in the inputAddress dataset as one could expect.

  "inputAddress": {
    "F7EFCACF2614": {
      "0": 11,
      "1": 14,
      "2": 11,
      "3": 14
    },

So, unless it is decided to transform the WPH-01 from a Switch to a Sensor I still vote for some more intelligence around "255".

My new proposal in pseudo code is that:

IF ("0" or "2" from inputAddress) IS_NOT "255", THEN ASSIGN Name + " left" to WPH-01 left button 
IF ("1" or "3" from inputAddress) IS_NOT "255", THEN ASSIGN Name + " right"to WPH-01 left button

To preserve backward compatibility, we may want to have and option to use WPH-01 as Switch or Sensor. Would be interesting to know if anyone is really using the WPH-01 integration in HA. I have no clue how it can be used.

I found an old answer from Icanos on this topic:

Sorry for the late response. WPH-01 only works by triggering a scene in Plejd and does not have a state in and of itself. You should however be able to trigger non-Plejd lights by the push of a WPH-01 button by listening for the trigger event from the switch that is created in HA.

This implies that some may use the current implementation, and therefore backward compatibility may have to be preserved.

Proposal:

  1. Rectify the current implementation by the proposal in pseudo code above
  2. Rectify the Ui bug presented in a post above (remove old stuff, when a WPH-01 has changed its behavior Switch/Scene)
  3. Add WPH-01 as a sensor as proposal in post above
  4. OPTIONAL: Add a [default] configuration option to remove the WPH-01

Considerations:

I fjärde kvartalet lanserar vi WRT-01, en helt trådlös tryckknapp i vridformat med en unik kombination av attraktivt pris och marknadsledande batteritid på hela femton år. Lanseringen är speciellt viktig för norska marknaden där installationer med trådlösa knappar är mycket vanligt. Det innebär att elektriker tryggt kan använda den i sitt arbete och lösa många problem med hjälp av trådlös kabeldragning. Tillsammans med vårt övriga sortiment har vi nu ett mycket konkurrenskraftigt erbjudande inom belysningsstyrning.

/Marcus

faanskit commented 3 years ago

Yes, you're right. Configuring scenes for both click and double-click completely removes the repetition of commands it seems. Having device + command or unassigned it works very differently.

Some more digging. Better explained in the MQTT log:

Dim Up
======
homeassistant/light/plejd/13/state {"state":"ON","brightness":179}
homeassistant/light/plejd/13/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/switch/plejd/14/state ON
homeassistant/switch/plejd/14/availability online
homeassistant/light/plejd/13/state {"state":"ON","brightness":250}
homeassistant/light/plejd/13/availability online

1 - DIM-01 reports its DIM level (before dimming starts) 2 - WPH-01 reports its consecutive state. Where it it the add-on reports dim level, but not over MQTT

2021-03-25 09:47:44 VRB [plejd-ble] Raw event received: 0e01100098013fb8
2021-03-25 09:47:44 VRB [plejd-ble] Decoded: Device 14, cmd 98, state 1, dim 184
2021-03-25 09:47:44 DBG [plejd-ble] Brytare right (14) got state+dim update. S: 1, D: 184
2021-03-25 09:47:44 VRB [plejd-mqtt] Updating state for Brytare right: 1, dim: 184
2021-03-25 09:47:44 VRB [plejd-mqtt] Sent mqtt state command for switch, Brytare right (14).
2021-03-25 09:47:44 VRB [plejd-mqtt] Sent mqtt availability command for switch, Brytare right (14). online

2021-03-25 09:47:45 VRB [plejd-ble] Raw event received: 0e01100098015fbd
2021-03-25 09:47:45 VRB [plejd-ble] Decoded: Device 14, cmd 98, state 1, dim 189
2021-03-25 09:47:45 DBG [plejd-ble] Brytare right (14) got state+dim update. S: 1, D: 189
2021-03-25 09:47:45 VRB [plejd-mqtt] Updating state for Brytare right: 1, dim: 189
2021-03-25 09:47:45 VRB [plejd-mqtt] Sent mqtt state command for switch, Brytare right (14).
2021-03-25 09:47:45 VRB [plejd-mqtt] Sent mqtt availability command for switch, Brytare right (14). online

3 - DIM-01 reports its DIM level (after dimming ends)

But, the broadcast is only sent once.

faanskit commented 3 years ago

I have now two switches (switch.brytare_right, switch.brytare_right_2), both named the same. I've seen this problem in my other HA installation when playing with the WPH. Only way to get rid of it is to re-install MQTT and Plejd :-/

Sorry for spamming, but I now know why it behaves badly. WPH-10 switch It lacks unique id. See the below MQTT log:

homeassistant/switch/plejd/11/config {"name":"Brytare left","state_topic":"homeassistant/switch/plejd/11/state","command_topic":"homeassistant/switch/plejd/11/set","optimistic":false,"device":{"identifiers":"F7EFCACF2614_11","manufacturer":"Plejd","model":"WPH-01","name":"Brytare left","sw_version":"0.3.1"}}
homeassistant/light/plejd/12/config {"schema":"json","name":"Relä","unique_id":"light.plejd.relä","state_topic":"homeassistant/light/plejd/12/state","command_topic":"homeassistant/light/plejd/12/set","availability_topic":"homeassistant/light/plejd/12/availability","optimistic":false,"brightness":"false","device":{"identifiers":"C061998B0B5F_12","manufacturer":"Plejd","model":"CTR-01","name":"Relä","sw_version":"2.1"}}
homeassistant/light/plejd/13/config {"schema":"json","name":"Dimmer","unique_id":"light.plejd.dimmer","state_topic":"homeassistant/light/plejd/13/state","command_topic":"homeassistant/light/plejd/13/set","availability_topic":"homeassistant/light/plejd/13/availability","optimistic":false,"brightness":"true","device":{"identifiers":"C12D372125FD_13","manufacturer":"Plejd","model":"DIM-01","name":"Dimmer","sw_version":"2.2.1"}}
homeassistant/switch/plejd/14/config {"name":"Brytare right","state_topic":"homeassistant/switch/plejd/14/state","command_topic":"homeassistant/switch/plejd/14/set","optimistic":false,"device":{"identifiers":"F7EFCACF2614_14","manufacturer":"Plejd","model":"WPH-01","name":"Brytare right","sw_version":"0.3.1"}}

This needs to be added for the WPH-01 switches as well.

faanskit commented 3 years ago

Sorry for spamming, but I now know why it behaves badly. WPH-10 switch It lacks unique id. See the below MQTT log:

The current unique id is not unique:

MqttClient.js 
  unique_id: `light.plejd.${device.name.toLowerCase().replace(/ /g, '')}`,

Device name can be re-used in multiple rooms. Propose to replace this with something truly unique, like plejdDevice or a combinatino of name and room.

  "plejdDevice": [
    "F7EFCACF2614",
    "C061998B0B5F",
    "C12D372125FD"
  ],
SweVictor commented 3 years ago

Yeah, well... Unfortunately that is a known issue. There was a PR quite long ago now, feel free to pitch in the best way to set unique id:s and mqtt paths for different things and maybe we can revive the work on uniqueness.

Main PR/discussion https://github.com/icanos/hassio-plejd/pull/102

Context/problems https://github.com/icanos/hassio-plejd/issues/161 https://github.com/icanos/hassio-plejd/issues/91

Might have missed some issues/PRs

faanskit commented 3 years ago

Yeah, well... Unfortunately that is a known issue. There was a PR quite long ago now, feel free to pitch in the best way to set unique id:s and mqtt paths for different things and maybe we can revive the work on uniqueness.

Ah...did not see that. I'll take a look at it. I do have a DIM-02 I can connect to my test-rig for additional tracing and logging. The issue seems to revolve around it and scenes, and now also WPH-01.

Practical question: Do you or someone else have a quick-guide how to get a simple dev environment up and running (on Windows or worst case a virtual Debian instance). Was planning to try a few things myself, but the threshold to start seems just too high. Got as far as having a local copy (git clone of fork) installed from /addons, then I got stuck since it seemed just to cumbersome to get code changes up and running.

SweVictor commented 3 years ago

Well. When I started I looked at the HA documentation for developing addons. Not super-helpful, but at least a start. My workflow is currently like this (Windows 10 workstation)

HTH

faanskit commented 3 years ago

Well. When I started I looked at the HA documentation for developing addons. Not super-helpful, but at least a start. My workflow is currently like this (Windows 10 workstation)

Thanks, then it is the hard way. I will shortcut a bit though:

Do NOT copy /node_modules to remote, that will give you issues

I don't even understand what that means :-)

SweVictor commented 3 years ago

Other great idea both on Windows and as addon is VS Code.

And yes, rebuilding is boring. You can also run the docket container directly in drv but then you need to be on a compatible host (I'm guessing Linux for BLE to work, haven't gone that route).

node_modules is created when you run npm in the plejd directory. You need Node installed. It fetches all the js dependencies specified in packages.json. And their dependencies. And their... After running you will have better code completion in your IDE ... but binaries for BLE will be built for the wrong platform/architecture which will break stuff if you copy to the HA instance.

faanskit commented 3 years ago

Other great idea both on Windows and as addon is VS Code.

Thanks.

After some tinkering, I now have the following installed the following programs:

I was able to run npm install successfully from within VS Code

C:\Users\Marcus\Documents\hassio-plejd\plejd> npm install
npm WARN deprecated babel-eslint@10.1.0: babel-eslint is now @babel/eslint-parser. This package will no longer receive updates.
npm WARN deprecated node-pre-gyp@0.17.0: Please upgrade to @mapbox/node-pre-gyp: the non-scoped node-pre-gyp package is deprecated and only the @mapbox scoped package will recieve updates in the future

added 416 packages, and audited 417 packages in 33s

53 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

Complete noob on node.js here...warning for stupidity below. My programming skills are from the good old days.

Now what? Is there a way to "compile" this on Windows? If I make a mistake, do I have to wait until it crash on the RPi? At least nothing happened with npm install when I injected garbage...

SweVictor commented 3 years ago

To actually run the code you need to boot up a dev docker environment (can be done from VS Code in some way with addons). Not my forte unfortunately). As an alternative you can run test code and run using node (node test/test.ble.bluez.js is an example). Primarily I recommend running npm run lint:fix to at least catch 'simple' errors before compiling on device.

If we get back to the issue that started this - what is the real use case of the WPH-01 in HA? I would assume ONLY what is in the title (trigger things), correct?

If so, I wonder if we should remove the switch completely (does it even do anything currently?) and look into how to send HA events over mqtt? Or - if that is not possible register some kind of device (sensor?) and trigger state updates?

I have been digging around the device registry setup code in PlejdApi.js and it's not super-clear to me what to do with non-output devices.

faanskit commented 3 years ago

If we get back to the issue that started this - what is the real use case of the WPH-01 in HA? I would assume ONLY what is in the title (trigger things), correct?

I'm not sure. For me it is so.
But, there might be a more direct use case as well. You may want to have virtual buttons in HA representing the real world. Take note that WPH-01 in HA is somewhat working and doing something.

However, the user experience for this is not consistent in current implementation.

Setup: CTR-01: Relay DIM-01: Dimmer WHP-01: Brytare

GOOD:

BAD:

Furthermore, when the button is assigned run scenes on single click - the setup is as we discussed before is corrupt since the code incorrectly assigns it to id 255.

If WPH shall remain as as button in HA, the implementation needs to be augmented: (1) The virtual state of the WPH in HA must follow the real state of the load it is assigned to. I cannot see how this can actually be done. I checked objectId, deviceId, assignments, etc..

(2) When assigned to scenarios, the WPH state must follow the state of the scenario

Conclusion Given that the current implementation is (partly) corrupt and that from my analysis it cannot be fully augmented with the data we have access to, I would recommend to remove it as a switch and instead implement it as a sensor.

SweVictor commented 3 years ago

Given that the current implementation is (partly) corrupt and that from my analysis it cannot be fully augmented with the data we have access to, I would recommend to remove it as a switch and instead implement it as a sensor.

I think I agree. At least WPH-01 and RTR-01/buttons without loads should be treated the same ("someone" had the idea to remove dimmers without loads from HA in https://github.com/icanos/hassio-plejd/pull/102#discussion_r602120188).

If we focus on loads and scenes as buttons/sliders in HA (and for scenes reset state back to "off" after trigger) and register all inputs as sensors instead I think we're on a good path. Agreed?

Question is also how to know what inputs to register as sensors. I have ~30 units which means 60-90 sensors since all support at least two inputs. And most have at least one input that is not used. Defaulting in Plejd to control it's own device output (and not sending BLE commands when doing so I think). So we could

  1. Register everything, try to group by device and have the HA user hide stuff at will (pretty standard and easy to understand)
  2. Register only inputs not controlling the same output. So, only register device inputs n where inputAddress[deviceId][n] !== deviceAddress[deviceId]. Probably more what people "want", but also very hard to understand why some devices list (some) inputs and others none at all.
faanskit commented 3 years ago

If we focus on loads and scenes as buttons/sliders in HA (and for scenes reset state back to "off" after trigger) and register all inputs as sensors instead I think we're on a good path. Agreed?

Agree

So we could

  1. Only register devices that "broadcast "as sensors. This implies WPH and WRT. If I am right, when using RTR it does not broadcast since it is connected to a remote device. Instead it will send direction directly to the target device.
SweVictor commented 3 years ago

Yeah. I'm thinking we could maybe complement that with a "latest command" sensor from Plejd addon globally?

Regarding inputs without loads attached, in my case RTR-01 "Dimmer 1 balkongdörr" (E352510EC81D, output 12), no broadcasts going on as far as I can see:

So, my take

faanskit commented 3 years ago

HOWEVER, while rotating the RTR-01 it is much quicker to listen to RTR-01 commands (virtual output group or otherwise) rather than wait for response back from actual device. So, for custom scenarios ("I want to control my Hue lamp brightness using Plejd") it might be nice to be able to pick up these messages as well. Alternative would be to require people to configure some non-used DIM-01 output as load to listen to and be fine that there is a slight delay.

Then RTR is not the right tool. Instead, WRT may be an option for these people. But I think WRT will have similar problem; but I have no such device so I cannot try it out... Remember, RTR is a electrical extension to the plug. It's the "third" "switch" added to the device. And, RTR must be connected to a a Plejd plug to even send.

SweVictor commented 3 years ago

Sure, I get your point, BUT - having a newly renovated house with 30+ Plejd devices it is to me quite reasonable to want to use the buttons and rotary encoders connected to them to control all kinds of things. I don't really feel like removing a DIM-01 with connected RTR-01 just to replace with a WRT-01. And as seen with the WPH-01 in this thread - even that might not be straight-forward.

faanskit commented 3 years ago

Sure, I get your point, BUT - having a newly renovated house with 30+ Plejd devices it is to me quite reasonable to want to use the buttons and rotary encoders connected to them to control all kinds of things. I don't really feel like removing a DIM-01 with connected RTR-01 just to replace with a WRT-01. And as seen with the WPH-01 in this thread - even that might not be straight-forward.

Yea, but it'll come with some form of workaround. Or do I miss something?

EPIC: As a Home Assistant user, I want to use my RTR dimmer to dim the light my Hue light so that I can have the same look and feel of all dimmers and switches

Problem statement The RTR does not send generic information, only targeted information.

Plejd behavior The RTR, mounted to any Plejd device must be configured to control at minimum one load, else it does not transmit. When the RTR is used, it will send consecutive updates directed to the configured load. When the "final" setting is transmitted, the load will send a final "confirmation"

Plejd data Relation between raw signalling event and API: Id 116 ->
Find 116 in inputAddress[], conclude it to be E352510EC81D and 2 -> Find E352510EC81D and 2 in inputSettings[], conclude it to be objectId = a0jk0NCRzh

Conclusion (needs to be checked) For RTR, the identifier towards Home Assistant can be “sensor.plejd.” + device[deviceId]+ "_" + inputSettings[deviceId].input For the WPH, the same identifier would work, at least when WPH is assigned to a load.

Recommendation Have an option "Register inputs as sensors" as it might throw a lot of sensors at the users who may not want the,

SweVictor commented 3 years ago

Well... In general multiple inputs can control the same output. While specifically 116 is unique other values are not (29 in my config is controlled by both E8F13EBED19E and D5428485A82E as one example). So, backtracking would result in multiple hits. ...which would also mean that you don't necessarily know which device was actually physically "handled" which might give the HA user confusing triggers.

So to me we could potentially support users "naming" output groups (virtual or otherwise) as a future thing.

So I'm back to supporting outputs only with the potential addon of letting HA know about all Plejd BLE commands.

faanskit commented 3 years ago

Well... In general multiple inputs can control the same output. While specifically 116 is unique other values are not (29 in my config is controlled by both E8F13EBED19E and D5428485A82E as one example). So, backtracking would result in multiple hits. ...which would also mean that you don't necessarily know which device was actually physically "handled" which might give the HA user confusing triggers.

Dang!

Can you upload a trace when you are using said RTR's are used. Would like to see what happens and how it relates. Come to think of it; there are no usecases where Plejd app needs to know which input triggered what - so it might not be possible to backtrack.

So I'm back to supporting outputs only with the potential addon of letting HA know about all Plejd BLE commands.

Nah. WPH-01 (that broadcast) needs to be a sensor.

SweVictor commented 3 years ago

Below log for 76, triggered by RTR-01 connected to D5428485A82E ("Fönsterlampor vardagsrum"). Removed mqtt stuff. Not sure if this helps.

2021-03-29 15:56:09 VRB [plejd-ble] Raw event received: 4c0110009700
2021-03-29 15:56:09 VRB [plejd-ble] Decoded: Device 76, cmd 97, state 0, dim 0
2021-03-29 15:56:09 DBG [plejd-ble] undefined (76) got state update. S: 0
2021-03-29 15:56:10 VRB [plejd-ble] Raw event received: 490110009800b77000
2021-03-29 15:56:10 VRB [plejd-ble] Decoded: Device 73, cmd 98, state 0, dim 112
2021-03-29 15:56:10 DBG [plejd-ble] Fönsterlampor vardagsrum (73) got state+dim update. S: 0, D: 112
2021-03-29 15:56:10 VRB [plejd-ble] Raw event received: 6f0110009800b77000
2021-03-29 15:56:10 VRB [plejd-ble] Decoded: Device 111, cmd 98, state 0, dim 112
2021-03-29 15:56:10 DBG [plejd-ble] Golvlampa vardagsrum (111) got state+dim update. S: 0, D: 112
2021-03-29 15:56:10 VRB [plejd-ble] Raw event received: 1d0110009800b77000
2021-03-29 15:56:10 VRB [plejd-ble] Decoded: Device 29, cmd 98, state 0, dim 112
2021-03-29 15:56:10 DBG [plejd-ble] Fönster vardagsrum (29) got state+dim update. S: 0, D: 112
2021-03-29 15:56:10 VRB [plejd-ble] Raw event received: 4d0110009800b77000
2021-03-29 15:56:10 VRB [plejd-ble] Decoded: Device 77, cmd 98, state 0, dim 112
2021-03-29 15:56:10 DBG [plejd-ble] Golvspotlights vardagsrum (77) got state+dim update. S: 0, D: 112
SweVictor commented 3 years ago

Nah. WPH-01 (that broadcast) needs to be a sensor.

Forgot that one. Are we sure? As I understand it:

How should the sensor behave?