current:beta
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
current:beta [2023/01/21 20:09] James Sentman 9.5.1 beta 6 |
current:beta [2023/02/03 15:38] (current) James Sentman |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| =====Beta Versions===== | =====Beta Versions===== | ||
| - | XTension version 9.5.1 beta 6 is available: | + | There is no beta version available at this time. |
| - | [[https://MacHomeAutomation.com/files/xtension/xtension_9_5_1b6.dmg]] | ||
| + | |||
| + | |||
| + | =====Beta 7 Changelog:==== | ||
| + | * NEW: The Video Encoder plugin will now run an Interface Script handler when a new encoding is complete. Open the Edit Interface dialog for the plugin and click to edit the Interface Script. Use the “Insert” toolbar item to add a default handler to demonstrate how it works. The handler is called “newFileAvailable” and it will pass you 2 parameters, the name of the video stream the recording came from and the full path to the new file. like: on newFileAvailable( streamName, filePath) | ||
| + | * NEW: If you’re using the “live recording” option for a stream then the recordings are never passed off to the batch encoder process but handled inside the video stream itself. In this case the same event in the previous item will be called in the video stream script. It is otherwise identical to the above. | ||
| + | * FIX: Units added to the list of shared items to the Home Kit are no longer in danger of getting an invalid Accessory ID. | ||
| + | * If you have Units that do not reload properly with this build as they were too broken before use the new trouble shooting functions now included in the Troubleshooting section of the [[supported_hardware:homekit|Home Kit Documentation]]. | ||
| =====Beta 6 Changelog:===== | =====Beta 6 Changelog:===== | ||
| - | * NEW: Direct support for ESPresence in the MQTT plugin. Simplifies using ESPresence devices with the MQTT plugin without having to do a lot of scripting. Turn it on in the Edit Interface dialog for the plugin and at least initially you should leave the Automatically Create Units for it turned on until it’s setup to your satisfaction. Full Documentation is coming but for the moment here. The ESPresence support will find all the devices that have been seen on your receivers, by devices I mean the bluetooth beacons and things like iPhones and the like, not the physical ESP32 devices running the receiver software. Each device will get a master device unit in one list in XTension. This will have the presence/absence of the device anywhere on your system. If no update has been received for it by the timeout set in the edit unit dialog then it will get turned off. While turned on the default label for the Unit will be the name of the room that the device is in. In addition to that another list of location units are created. For each device another unit is created for each room they may be in. These Units will turn on and off based on regularly walking the list of recently received messages and finding the one with the shortest distance to the receiver. I’m not 100% sure about this logic or layout or anything else yet so please let me know if this is the kind of thing you’d expect from this or not. More direct device support is coming. I’m working on Tasmota next as it also has a rather complex MQTT topic structure. | + | * NEW: Direct support for ESPresence in the MQTT plugin. Simplifies using ESPresence devices with the MQTT plugin without having to do a lot of scripting. Turn it on in the Edit Interface dialog for the plugin and at least initially you should leave the Automatically Create Units for it turned on until it’s setup to your satisfaction. Full Documentation is coming but for the moment here. The ESPresence support will find all the devices that have been seen on your receivers, by devices I mean the bluetooth beacons and things like iPhones and the like, not the physical ESP32 devices running the receiver software. Each device will get a master device unit in one list in XTension. This will have the presence/absence of the device anywhere on your system. If no update has been received for it by the timeout set in the edit unit dialog then it will get turned off. While turned on the default label for the Unit will be the name of the room that the device is in. In addition to that another list of location units are created. For each device another unit is created for each room they may be in. These Units will turn on and off based on regularly walking the list of recently received messages and finding the one with the shortest distance to the receiver. I’m not 100% sure about this logic or layout or anything else yet so please let me know if this is the kind of thing you’d expect from this or not. More direct device support is coming. I’m working on Tasmota next as it also has a rather complex MQTT topic structure. **NOTE** if you enable the ESPresence support while the plugin is running you’ll need to disable and re-enable the plugin for that to take effect. |
| * NEW: If there are important errors during startup a new list window will open to contain them separate from the log. This window is called the “Startup Messages” window. If you see it then there is something you might need to address. It will either contain the necessary information or suggest you look at the log for more info. This way messages on database load that might get scrolled off the top so fast you don’t see them will get noticed more easily. | * NEW: If there are important errors during startup a new list window will open to contain them separate from the log. This window is called the “Startup Messages” window. If you see it then there is something you might need to address. It will either contain the necessary information or suggest you look at the log for more info. This way messages on database load that might get scrolled off the top so fast you don’t see them will get noticed more easily. | ||
| * NEW: Multiple Interface Collision Detection. Previously it was possible to create a situation where a unit was set to use 2 interfaces to receive, but one of them could have another unit with the same address which would keep the multiple interfaces from working properly. During startup if this is seen while loading the database an error is written to the log and a startup message is created in the above mentioned window telling you that it has happened and what the 2 units are so you can more easily figure out why messages aren’t getting routed as you expect. | * NEW: Multiple Interface Collision Detection. Previously it was possible to create a situation where a unit was set to use 2 interfaces to receive, but one of them could have another unit with the same address which would keep the multiple interfaces from working properly. During startup if this is seen while loading the database an error is written to the log and a startup message is created in the above mentioned window telling you that it has happened and what the 2 units are so you can more easily figure out why messages aren’t getting routed as you expect. | ||
| Line 20: | Line 26: | ||
| * FIX: Fixed a rare and unusual problem with syncing data between XTension and the plugins. This could have caused the loading of units from XTension to be short circuited and some updates to be lost to the plugin. | * FIX: Fixed a rare and unusual problem with syncing data between XTension and the plugins. This could have caused the loading of units from XTension to be short circuited and some updates to be lost to the plugin. | ||
| * FIX: The logging of available RAM that XTension does at startup was logging it with the wrong suffix showing that you only had kb available when it was really mb or gb. | * FIX: The logging of available RAM that XTension does at startup was logging it with the wrong suffix showing that you only had kb available when it was really mb or gb. | ||
| + | * FIX: I’ve made it possible to change the type of a Unit while the interface it’s connected to is running. This is working well in my testing but it is possible that there are situations in some plugins that would not properly follow along. If you have any trouble doing this record the errors to send to me and then just disable and re-enable the interface to get everything working properly again. | ||
| * CHANGE: This shouldn’t affect anything, but keep an eye out in case it does. Plugins that have scripting handlers now register them with XTension. XTension will verify that a handler you’re trying to call is available before sending the command to the plugin. If you try to call a handler that does not exist then the script will be returned an error. Previously once the command was sent to the plugin it was assumed to be handled. So if you had called piblish( “topic”, “payload”) instead of publish() it would not have been able to log an error, it would just silently fail. So watch for new script errors where this might be being caught now when it was never before. | * CHANGE: This shouldn’t affect anything, but keep an eye out in case it does. Plugins that have scripting handlers now register them with XTension. XTension will verify that a handler you’re trying to call is available before sending the command to the plugin. If you try to call a handler that does not exist then the script will be returned an error. Previously once the command was sent to the plugin it was assumed to be handled. So if you had called piblish( “topic”, “payload”) instead of publish() it would not have been able to log an error, it would just silently fail. So watch for new script errors where this might be being caught now when it was never before. | ||
current/beta.1674331785.txt.gz · Last modified: 2023/01/21 20:09 by James Sentman
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
