Goose66

@JBalog Was this resolved? Also, did you delete and rediscover your devices after installing the update?

Does the Bond Home app show more commands than just Open or Close? Also, what is the device type up at the top of the node details in the Admin Console? A Shade should never show “On” or “Off,” but “Open” and “Close” (at a minimum). Adding a screen grab from the Admin Console would be helpful.

The docs suggest it may be a Pro only thing, but you can try deleting and re-discovering your shades to see if they show up as having position support.

I’ll take care of this in the patch. Let’s see what else shakes out this week.

Do you have a Bond Bridge Pro?

Look here:

Look here:

A new version v3.3.15 of the Bond plugin has been uploaded. This version adds enhanced support for shades (see below) and adds the ability to restart the BPUP listener thread and connection to the bridge if it fails for some reason, e.g., network troubles or power loss affecting the Bond bridge but not IoX/PG3. I have no real way to test these changes since I don't have any shades, so before I update all the documentation for this plugin, if a few of you (e.g., @tlightne and @JBalog) can bang on it for a few days and let me know what isn't work, that would be great. I can roll out a patch to fix any issues before updating the Release Notes. This version adds several commands to basic Shade nodes: Start Opening, Start Closing, Stop (Hold), Toggle Opening, and Preset Opening. The "Stop (Hold)" command stops the shade when in motion from an open or close command. Because most if not all shades have no way to report position back to the bridge, then status generally changes to "Open" when the "Stop (Hold)" command is used. "Toggle Opening" is pretty straight forward. "Preset Opening" opens the shade to a preset level (set by the shade remote) and is referred to in bond as "My" for some shades. These commands may or may not work for different shades, and if one doesn't work, a Warning may show up in your plugin log. On some shades, if the "Stop (Hold)" command is issued when the shade is not in motion, the "Preset" functionality is invoked (the likely case when the remote only has one button to perform both functions). "Start Opening" and "Start Closing" just call open and close, respectively. However, "Start Opening," "Start Closing," and "Stop (Hold)" map to FDUP, FDDOWN, and FDSTOP IoX commands, respectively. So the theory is you can drop a shade into a IoX scene with a Insteon SwitchLinc, and get easy control: tap top of switch to open; tap bottom of switch to close, press and hold top of switch to start opening, release switch to stop opening, etc., all without programming. If anybody can test this, that would be great. For shades that support positioning, there is a new Shade node that adds a "Set Position" command along with "Increase Opening" and "Decrease Opening" commands that increase or decrease opening by 10%. This node also reports the position as a percentage if not fully "Open" or "Closed." Several Notes: The Bond Home app and Bond API report position as a percentage of "closed," i.e., 0% is open and 100% is closed. IoX "Barrier Status" UOM reports position as a percentage of "open," i.e., 0% is closed and 100% is open. The conversion is done in the plugin so you should keep this in mind. If you have a shade that supports "Set Position" commands, either because it's native to the shade or you've set the "Course Time" in the Bond Home app for the shade and the Bond Bridge Pro is tracking it's position, then you will need to delete the existing shade nodes and the re-discover nodes from the bridge to get them to load with the right node definition. Let me know what works and what doesn't.

Coming in next release.

Ok. Anything else? Anyone? Bueller?

Here are a couple things to try right off the bat: 1. Try navigating to http://isy in a browser. If the version of IoX (the OS/firmware on the ISY994) is older, you might get lucky! 2. Login to your network's router or other device providing DHCP on your LAN and look for a device with a name such as "isy..." or a MAC address matching the MAC address on the bottom of your ISY. Try using that IP address to navigate to http://<ipaddress> or http://<ipaddress>:8080. If either of those work, you can try to login with admin/admin credentials. If you have Java installed, you can launch the Admin Console from those webpages.

What plugin?

I can't speak for MyQ doors, but it is very stable for my dry-contact Genie doors. Never had an accidental opening or anything like that.

No that’s what I meant. At least on the Martin Jerry Tasmota devices, if you use %topic% in a rule, it is replaced with whatever is specified for “Topic” in the MQTT configuration.

Does "tasmota/stat/%topic%/STATE" work instead of having the actual name of the device in there? If that works, and you post back the exact rules that you used, I can make the Tasmota Plugin configure the HPSensor devices with those rules upon discovery. I need to roll out a new version to fix the failure on bad MQTT data that we found while debugging this.

The Tasmota “drivers” for the device are here: https://github.com/blakadder/berry-drivers I’m probably out of my depth here, but looking at the Berry code, it seems the driver is updating the Tasmota core OS with the state values every 50ms. You could probably learn Berry and fork this driver code and add mqtt publishing on value changes. Another possibility: if someone wants to send me one of these, I would consider writing a plugin for the ESPHome firmware. Tasmota is just not a great device OS. That’s why I never expanded the device support in the Tasmota plugin. The ESPHome firmware (which appears to be available) may offer better features for this particular device. I know it offers better programming interfaces.

From a quick look at the code, this should be working. As I said, the code handles tele/ and stat/ messages in exactly the same way, so simply substituting "stat" for "tele" should work. Just FYI, this is not the case for other Tasmota devices -- the formats of the stat/ and tele/ messages are very different. I assume I implemented the HP Sensor code this way because it was all the information I had at the time (I don't own any of these devices and was just working off @EWhite's logs/input). All that said, there are several things to try in debugging this: 1. It could be a simple matter of timing. Since the teleperiod is set to the minimum of 10 seconds, the device itself may be switching the Presence (ST) driver value back to 'Unoccupied' every 10 seconds and you just aren't seeing IoX update to 'Occupied' because of this timing. So first try setting the teleperiod to a higher value, e.g. 30 seconds, through the device's Tasmota console. 2. When the plugin updates the Presence (ST) driver value from 'Unoccupied' to 'Occupied' it also sends a DON command. And it sends a DOF command when vice versa. So even if the resetting back to 'Unoccupied' is happening every 10 seconds by the tele/ messages, you should still be getting these commands for the device. Try writing an IoX program with " 'DR_Occupancy' is switched On" conditions to see if you can detect the changes. 3. Turning on Debug level for the plugin logging and then trying a few times and DMing a plugin log file (not PG3x log) to me would be the logical next step.

If you can write rules to generate state messages on state changes, the plugin should respond to them. As a starting place, look here: https://tasmota.github.io/docs/Rules/#conditional-rules I can provide specifics as to what the stat messages should look like, but for the most part should just be the tele messages with tele/ replaced with stat/

I believe MQTT Explorer can export logs of messages by topic. There should be stat/<device id> and tele/<device id> topics for each device

The teleperiod should be the periodic telemetry messaging for all tasmota devices, right? In other words, the periodic updates in state sent to the Telemetry "tele/" subtopic. But shouldn't the device send state changes to the State "stat/" subtopic as well when state changes? For example, with switches, you get telemetry messages every 90 seconds or so, but you get state messages instantly. Perhaps we need another MQTT Explorer log output watching one of these things to inventory the messages. And if the device doesn't send state messages on state change by default, it seems like it would be easy to set a Tasmota Rule to send a state message upon state change for each state you want reported right away. Also, there appears to be an "Occupancy Delay" parameter that can be set through the plugin (via Admin Console). What is that set to? Is it possible that is where the 10 second delay is coming from?

Just to be clear, this is a problem with the sensor device, not the Tasmota plugin, I assume.

Right. That’s exactly what it was. I also have that USB interface board for loading the flash module. I didn’t remember all the details.

There’s an SSD (not SD card) on the board. Don’t remember the actual interface protocol(s). NVMe? PCIe? eSATA?

Sounds like an SSD card problem. Hope not, but I went through something similar. IIRC, UD had to send me a new module.

Manually yes, but if I went to the device in UD Mobile or Admin Console and turned it on, then the keypad light wouldn’t turn on. And if the device is in other scenes and is turned on or off via those scenes, then the keypad light wouldn’t be updated. The only way to keep them in sync is with a key state update program.