Differences

This shows you the differences between two versions of the page.

--- current:beta [2021/05/20 17:59]
James Sentman
+++ current:beta [2023/02/03 15:38] (current)
James Sentman
@@ Line 1: / Line 1: @@
 =====Beta Versions=====
-Everything in this beta is now included in the current release as of 9.4.40 and it will no longer be available for download.
+There is no beta version available at this time.
------
+=====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:=====
+  * 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: 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: MQTT Plugin now better handles server reconnects. If the server drops out due to network issues or rebooting or whatever and then recovers all your existing subscribed units will re-subscribe and continue to receive data.
+  * NEW: MQTT Plugin now has a separate field for the outgoing topic. If updates from the Unit need to be published to a different topic than the one subscribed to for updates from the mqtt server that can now be entered there.
+  * NEW: MQTT Plugin now lets you set the QOS and Retain values for each individual Unit in the Unit Setup Dialog.
+  * NEW: MQTT Plugin implements a generic scripting handler just called “publish()” that lets you publish any string to any topic from anywhere. If you’re doing it from the Unit’s on or off script no other handling is needed it’s just:publish( “/my/topic”, “shower in use”) if you’re doing it from elsewhere use the tell xInterface “name of your MQTT plugin” to publish( “/my/topic”, “shower in use”)
+  * NEW: The Video plugins now insert all the event data that you create while recording with the record from “whatever” for 30 info “name the event here!” as well as the timestamp of the frame into closed caption data. This can be displayed when streaming the snippet from the web interface or when just viewing it off the disk. It is superior to physically overlaying the text onto the actual video stream as it can be moved around by the user so that it doesn’t obscure something you want to see and it is readable and the same size no matter how small a thumbnail of the video you’re looking at.
+  * NEW: The video plugins now provide the same event listing in the Web Interfaces that the old Video Pitcher program did. So they will show up there as well as closed captioned.
+  * FIX: Fixed a problem with the MJPEG camera streaming plugin that would cause a slight bump in CPU usage every time the connection was lost and recovered due to it not properly closing a thread that would keep trying to work in the background even after it had been replaced.
+  * FIX: Fixed an issue with the Amcrest API camera plugin that would cause the plugin CPU usage to peg at 100% if the camera connection was lost.
+  * 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: 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.
+This is probably going to be the next release unless something else exciting comes up.
-A notarized beta of XTension 9.4.40 is available as of 4/25/2021
+=====Beta 4 Changelog:=====
+Change log:
+  * NEW MQTT Client plugin. No wiki documentation yet. Read the information on the unit pages carefully. Select how you’re going to get the data out of the topic there are currently 3 types of parsing to get it out. There will be more for more complicated devices. Then enter the MQTT Topic into that field and if the Unit is 2 way select the way you’re going to send data back to the server. There are currently many choices but none that will yet easily handle XML or JSON values or more complex structures that would require scripted parsing and scripted re-creation of such a structure. If you have examples of such things please send me the topic data from them and as much other info as you can put together so I can make sure that the release version of the plugin can handle it. To see all the topics as published turn debug mode on for the plugin instance. Note that there is no attempt to automatically create Units for an MQTT server. That would result in a LOT of Units. Create only the Units you need with the specific topic paths that you wish. Use a problem like MQTT explorer to find what they are on your server. Also note that this is NOT a broker. This is a client and can connect to a broker elsewhere or running on the same machine. I recommend the Mosquitto server at the moment since that is what I have been testing against.
+  * FIX data logged from a Unit using the contextual menu item of log debug data will now have the Unit set so that you can filter for that and see it in the log. Makes it easier to gather debugging information for me.
+  * Fixed an error in the error logging in one place in the basic plugin includes. This could have caused a confusing error and would have stopped the logging of the actual error and information that I would need to fix that. This was initially plaguing folks with the Barix plugin as it was trying to convert older Units. I have found an interface on my system that also generates this error so I will be able to fix it now, but if we were working on this please send me the new error message to help me get this squashed and properly working
+=====Beta 1 Changelog:=====
-[[https://MacHomeAutomation.com/files/xtension/xtension_9_4_40b1.dmg|XTension Beta Version 9.4.40 (build 1040)]]
+Changes in the previous beta.
+  * NEW Plugin for No Hassle AV 4x4 HDMI switchers. [[supported_hardware:nohassle4|Documentation is here.]] This supports (or tries to) 4 different 4x4 size devices.
-This version includes a beta plugin for SDR radios via a wrapper for the rtl_433 application. The current support is incomplete but should support everything that the now more difficult to obtain RFX radios and most, but not all, of the speciality devices that the rtl_433 program supports. I will endeavor to complete special handling for everything that needs it before the release but if a specific device you are using does not work with this beta but is supported by the rtl_433 software please let me know and I’ll make sure I support it’s custom data output. As of this release every weather type instrument should work from Oregon Scientific like the RFX and also those from accurite and others that are supported by the rtl_433. For more info on the rtl_433 software please see [[https://github.com/merbanan/rtl_433|rtl_433 git hub page]] for more info on what it supports or doesn’t. Please note that the rtl_433 plugin is a receive only device and cannot transmit to control the devices you are receiving.
+  * NEW Plugin for No Hassle AV 8x8 HDMI switchers. [[supported_hardware:nohassle8|Documentation is here.]] This supports (or tries to) 3 different 8x8 size devices.
+  * FIX: Fixed a problem loading Unit Icon files that were not JPEGs. PNG’s and GIF’s load normally again. This was broken recently when I switched to a faster jpeg parsing library.
-NOTE that rtl_sdr supported radios are tested. The software is present for the soapy_sdr supported radios but as I don’t have any of those I have not tested and you may encounter problems. If you are using one of those please send me any log output if there is any problem. If you don’t have any problems please let me know that also.
+  * FIX: more bugs in the Phillips Hue plugin that would have caused an error, and then an error in the error handling when it tried to log the wrong data.
+  * Database Format Change: For more than 5 years I’ve been keeping 2 copies of the Unit Properties data to make it easier should anyone have to revert to an earlier version after using the newer version. This build stops doing that and removes the old file potentially making the database quite a bit smaller and therefore faster to load and easier to manage. At this point if you need to revert to a version more than 5 years old you’ll have to use the backup file that is zipped up when each new version is loaded. Or just be OK with losing the Unit Properties from your database.
-In addition to the rtl_433 plugin this build also includes a fix for the database sharing where it might throw an error because of it trying to use the wrong version of the python libraries to connect via a secure connection. This should be fixed in this version as well.
+  * Enumerated Values for Units are now individually trimmed of leading or trailing spaces. So if you enter the values like “slow, medium, fast” the system will know you didn’t actually mean those spaces to be part of the enumerated values.
+  * If a plugin has an empty description the name in the popup will no longer show an empty set of parenthesis after the name.
-There is not yet a wiki page devoted to the SDR radio info so I’ll place some of this info here:
-====XTension Settings:====
-Setting up the SDR should be very straightforward assuming that you have only one radio connected to the Mac in question and you only want to receive already supported devices. The current XTension configuration screen, subject to many changes before release, looks like this:
-{{:current:rtl_433_settings.png?400|}}
-For any radio connected to your mac and receiving the supported 433 devices you should leave this as is.
-If you are using a supported SDR on the Mac itself then none of the following about the raspberry pi is needed. This is only needed if you wish to use a pi as a remote host for an SDR. If you wish to run a remote connection to a host pi then select “remote via ssh” from the popup menu labeled “connection type"
-====Raspberry Pi Remotes:====
-**Note that this section is only necessary if you are wanting to connect to a radio hosted remotely via a raspberry pi. Otherwise skip this!**
-Running SDR software on the Pi takes a considerable amount of resources. I would not recommend running this on a Pi Zero or a very old device. It runs just fine on a previous generation Pi 3B+ and will run perfectly on the newer pi4’s without having to purchase the more expensive ones with more memory unless you want to host multiple radios.
-If you wish to have many radios installed away from the XTension mac you can install the rtl_433 software on a raspberry pi and place that anywhere on the local network. You can create additional interfaces to connect to any number of raspberry pi hosts. This functionality is also working as of this beta version.
-The connection to the raspberry pi is via an ssh session. There is no way to save the password into the interface so you must configure your mac and the pi to connect via ssh without a password. If you have never done this on your mac you must first create an ssh key that you can share with the pi. Start the terminal and enter this command:
-<code>
-ssh-keygen -t rsa
-</code>
-The switch for -t rsa may not be needed depending on the OS version. Use the default key name and do not set an encryption password for the key.
-now you need to send that to the raspberry pi so that you can connect from your mac to the pi without having to send the password each time. This is also done via the command line on the Mac to the pi. (make sure you have changed the default password on the pi and set it’s hostname to something other than the default of raspberrypi.local or you’ll run into trouble later)
-the command to register your ssh key with the pi is:
-<code>
-ssh-copy-id pi@thePiAddressOrName.local
-</code>
-if your user is other than the default pi make sure to change that. You can connect via the IP address of the pi if you have assigned it a static IP or via it’s hostname.local as long as you have changed it from the default of raspberrypi.local or you’ll not be able to setup more than a single pi on the network.
-You may have to answer several questions about are you sure if you have setup other pi’s as the keys will have changed and ssh will warn you that it can’t verify that you’re connecting to the right machine. If you have setup other pi’s in the past it may refuse to connect at all because it’s in your known host file with a different machines key. If thats the case you need to edit your known hosts file to remove it. If you haven’t ever done this you can do it at the command line via something like:
-<code>
-nano ~/.ssh/known_hosts
-</code>
-then use the control-w to find “raspberrypi.local” and delete that whole line. Then save by doing a control-o and then exit with a control-x. There are many many other resources for more info on doing this on the web if you need more info.
-Once that is done and you have copied the key via the above please do test that you can ssh in without a password. It may require that you do it once manually and OK the fact that it can’t verify the key if you have every connected to another one and you need to do that before the software can connect without your attention so once that has completed test it via ssh’ing in via a regular command like:
-<code>
-ssh pi@yourPiAddress.local
-</code>
-it may ask you “are you sure” because something cannot be verified. Please answer yes and if you end up at the ssh prompt for the pi then all is well. You can then move on to compiling the rtl_433 software on the pi.
-====Installing rtl_433 on the pi====
-There are 2 steps to installing the software on the pi. You need both the low level SDR radio software and the rtl_433 software. They are very easy to install.
-===Load Up The Pi:===
-If you haven’t already load up the most recent pi software and do any updates available. I wont post instructions for this here, if you can’t do this and can’t find instructions on the internet for it you probably shouldn’t be trying this ;) The program will work with the “lite” versions of the raspian images or the desktop and full installs but those are not necessary and if you’re not using the pi for desktop work you will only be wasting space by using those.
-===Make Sure GIT is installed:===
-try this command to see if git is installed on your device or not:
-<code>
-git --version
-</code>
-if you get a “command not found” error then you need to install git. That command is:
-<code>
-sudo apt install git
-</code>
-it will tell you that another 33meg of disk space or other is needed and you need to say Yes so that it will install
-Once that is finshed you can retry the git --version command. As of this writing the version installed is 2.20.1
-===Install Pre-Requisites:===
-The following packets are required to finish the rest of the install. If you already have any of them then the installer will just skip that part:
-<code>
-sudo apt install cmake libusb-1.0-0-dev build-essential autoconf libtool pkg-config
-</code>
-===Install rtl-sdr:===
-<code>
-git clone git://git.osmocom.org/rtl-sdr.git
-cd rtl-sdr
-mkdir build
-cd build
-cmake -DINSTALL_UDEV_RULES=ON ..
-make
-sudo make install
-sudo ldconfig
-</code>
-===Install rtl_433:===
-<code>
-git clone https://github.com/merbanan/rtl_433
-cd rtl_433
-mkdir build
-cd build
-cmake ..
-make
-sudo make install
-</code>
-===Setup For Remote:===
-Once you’ve done all that you can select “Remote via SSH” from the Connection Type popup as shown above and unless you changed the install locations on purpose the defaults should all work just fine and you can connect an interface to a device connected via USB to a remote raspberry pi. If you need to have more than one radio connected to the same mac or raspberry pi that is also possible, but read on for even more configuration:
-===Multiple SDR’s:===
-XTension will support multiple SDR radios on the same machine via the serial number of the device. Unfortunately all the devices I have seen come with the serial number set to “0000001” or something similar. So you have to use the rtl_eeprom tool to set the serial number before filling it into the XTension interface as shown above. This will work for both local SDR’s as well as those connected to remote Raspberry Pi hosts. I will not include instructions for how to use the rtl_eeprom tool here, please look those up on the wiki page for the rtl_433 page linked to above. You’ll find the app compiled for the Mac inside the plugin folder which is inside the XTension app. If you control click on XTension in the finder and select “show package contents” and then open the Contents folder, and then the Resources folder and then the Plugins folder and finally the “rtl_433.isf” folder you’ll find the supporting applications such as rtl_eeprom. You can take a terminal session in there and then use the app to write a specific serial number or id string to the radio which you can then use in the **SDR Serial Number** field of the XTension settings window as shown above.
-===What it doesn’t do:===
-Currently temperature, humidity, rain and wind sensors are supported from multiple manufacturers. Far more than the RFX radios supported. What does not work well yet are all the 433Mhz remote control devices. They will create units in XTension but they are not filtered properly for debouncing and repeats and such. You’ll also find that if you leave the “create unit in XTension automatically” checkbox turned on that you’ll receive things that have nothing to do with an actual device but that are just noise. I would not rely on this for those types of devices yet. The temperature and other RFX receivable devices all seem to work very well for me as of this moment.

Mac Home Automation

User Tools

Site Tools

Differences

Page Tools