Differences

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

--- current:beta [2021/05/20 17:59] – James Sentman
+++ current:beta [2023/07/01 14:26] – 9.5.3 beta 4 James Sentman
@@ Line 1: / Line 1: @@
-=====Beta Versions=====
+=====Beta Version (9.5.3 b4)=====
-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.
+The currently available beta version of XTension is 9.5.3 beta 4 (build 1082) released on 7/1/2023
------
+[[https://machomeautomation.com/files/xtension/xtension_9_5_3b4.dmg|Download Xtension 9.5.3 beta 4]]
+Keep in mind this is a beta build and may contain bugs or annoyances and not all expected features or changes may yet be implemented. No database changes are made so if you to have to revert to the last release version simply replace the application with the previous version and all will be well.
+**Changes in Beta 4:**
-A notarized beta of XTension 9.4.40 is available as of 4/25/2021
+  * **Hubitat Plugin:**
+    * More updates and changes to the new handling of “string” data types. If there is a number at the beginning of the string then that will be parsed and sent to XTension as the new value of the Unit. The Unit Description is no longer set to the raw string value. A new Unit Property called “Raw Value” is now set to the full value of the string and programmatically you can do with that what you wish. If there is no numerical value or if the raw value is more complex then the value of the Unit will be set to 0 and the default label for the Unit will be set to the Raw Value. No default label is set if a number is found at the beginning of the string so that your own formatting and suffix options in XTension will be used instead. You can still do whatever you wish with the Raw Value property, but the values are just too non-standard to do much more with them directly in XTension without custom scripting to handle values that really just should have been a number and a suffix...
+  * **Amcrest Camera API:**
+    * Fixed an issue that caused some cameras not to work with the event system. If you find that any cameras still do not send you events but also dont log any other communication or connection errors please let me know we can gather some more info.
+    * Added a check to the enableEvents() command so that it will not try to enable events that the plugin does not recognize as valid. This keeps you from either getting nothing, or getting an error message each time the unknown events is sent. If there are events that I am not handling that you know about and would like to get please let me know we can gather more info about them and set them up.
+  * **Last Activity:** A change to the Last Activity date handling. Previously if a Unit had never had any activity after being created it would show a last activity date of the time the program was last started. This caused confusion in list windows when sorted by date and is something I’ve been meaning to deal with forever. Now if a Unit has no last activity date it will display as “Never” in the list window, but be sorted as if the date had a total seconds property of 0. In other interfaces or via the scripting commands it will return a date with the earliest date/time that the normal unix date can hold so something like 1/7/1903 or whatever that is. So it will sort properly and no longer be confusing.
+  * **Home Kit:**
+    * Updated the Home Kit libraries some but not all the way to current. They have made some significant changes in the most recent builds that break it completely for us in the short term though I”ll keep working on that. This is unlikely to either cause or cure any problems people may be having with it as the only changes were to the handling of Thermostats. Home Kit now always sets the Mode of the HVAAC to Auto. This is not due to anything that I can do anything about easily and is a decision that Apple has made. I may be able to override some of this handling to not accept those changes from the thermostat but only send them from XTension or something like that if it is a problem.
+  * **Beta Fix:** Cleaned up some potential error logging in the sharing setup dialog. This was introduced in one of the earlier betas and might have caused problems setting up new unit sharing to the shared database system or the Home Kit plugin.
-[[https://MacHomeAutomation.com/files/xtension/xtension_9_4_40b1.dmg|XTension Beta Version 9.4.40 (build 1040)]]
+**Changelog betas 1 through 3:**
+  * **Hue Plugin:**
+    * Hue Plugin: Fixed an issue where it could send continual updates for a sensor value even if the value had not changed.
+    * Hue Plugin: Fixed an issue where the temperature format was not saved, sticking all readings in F.
+  * **Video System:**
+    * Video Encoder Plugin: Added a checkbox so you can suppress logging of video encoding times if you wish.
+    * Video: Removed error logging for stalled streams as this would fill the log if the camera was offline for any length of time. To log this information please implement the stalled script handler in the Interface Script and write to the log whatever information is helpful.
+  * **Sysinfo Plugin:**
+    * System Info Plugin: no longer claims in it’s startup log message to be the Disk Space plugin.
+    * Fixed an incorrect default link to the boot volume so that this will work without having to edit it each time.
+  * **Internal Python:**
+    * Python: A symlink to the built in python3 version is now added to /usr/local/bin/pythonxt so if you wish to use the built in version for your own script you can just execute it via that command.
+    * Python: XTension changes many environment variables in order to use it’s internal version of python. If you are running a system version of python in your own script from a shell in XTension this may cause errors or make it unable to find installed modules. You can now use a scripting command “revertENV()” in your script before invoking your shell script to reset the environment to the system default just before launching it which will solve most, but probably not all of these issues. Note that you should do this immediately before starting any shell script as XTension will change it again as needed when launching plugins.
+  * **Web Remote:**
+    * Web Remote: New documentation of the hashing of web remote links to immediately go to a specific page or view. This can be useful if you are saving specific links as iOS shortcuts, or creating a Kiosk type application. This is not a new feature, but was never properly documented. [[webremote:kioskview|Kiosk View and Hash Linking Info]]
+    * Web Remote: Added several new scripting commands to control sessions in the web remote. This lets you programmatically change the view on a specific device to say, a video page or a View in response to motion or other event. Additionally you can script a popup alert or timed message in any color to display on all active sessions or only on specific ones. [[webremote:scripting|Scripting Web Remote]]
+    * Web Remote: Added support for a resource folder that will be served as regular files through the web remote built in web server. This way if custom controls or other features you are adding need to load a specific image or other support file they can do so if you put it in the resources directory inside your XTension Database. [[webremote:resourceserver|Resource Server]]
+    * Note that these changes have not been rolled into the mobile web remote plugin, only the desktop version.
+  * **Plugin API:**
+    * A new key for the info.json file that will allow a plugin to receive any scripting command the user issues. This simplifies some kinds of plugin tasks at the expense that users script will not know if the command succeeded or not, all commands will just be sent and forgot. This does not affect regular using the app, only plugin developers.
+    * Added the capability for plugins to display information in new text windows and to append to or change the display of one without opening a new window each time. This mostly affects plugin developers but I used it in the new and changed show info commands in the Amcrest API plugin above.
+    * All plugins now log their version number in the startup message from the information stored in their info.json file. This will keep them from always being wrong as I forget to update it in 2 places instead of just 1.
+  * **Hubitat Plugin:**
+    * Hubitat: Added entries to the “insert” toolbar menu for the central scene Held, and Released events to make it easier to script these without having to visit the wiki to look up the specifics.
+    * Hubitat: Added support for Energy and Usage units. If a device reports these values a Unit will be created for them.
+    * Hubitat: Added support for values that come in as “STRING” rather than numerical or enumerated. This is a bit of a hack as it’s impossible to know what format these things will seem to be. First the value is scanned to see if there is a number in the first part of the string. If there is then the Unit will be dimmable and the value will be placed in the value of the Unit. for example: “3.2 Hours” would create a dimmable unit and set the value to 3.2. The Default Label and the description for the unit will be set to the string as it is sent. So even though the Unit value is 3.2, the display of the value in any XTension interfaces would be “3.2 Hours” If there is no number at the beginning of the string then the UNit will not be dimmable and it will just have it’s default label and description set to the text. You can capture the set description event in the unit’s on script to get the text and parse manually if you need to.
+    * Hubitat: Some devices from the Hubitat will now have more descriptive, or less long winded names when created by default. This will mostly effect the Thermostat units but some others can be made better with this too. This does not affect Units already created, and you can always manually edit the unit’s name once it’s created to be whatever you like in either case.
+    * Hubitat: The list of supported commands for each Unit is now saved to a [[dictionary:unitinformation:getunitproperty|Unit Property]] so  you can see all the commands the device supports directly. You may still have to discover what parameters are required, if any, but this will make it easier to do things to the Units via the [[https://www.machomeautomation.com/doku.php/supported_hardware/hubitat#sending_device_specific_commandsm|sendDeviceCommand()]]
+    * Hubitat: Push messages from the Hubitat that are sent when a software update is started, or when the device is about to reboot to install a software update will now just log that information rather than generate an “unknown push message” error in the log.
+  * **Amcrest Camera API:** All the additions mentioned below have been added to the [[video:api:amcrest_hd|Amcrest Camera API Documentation]]
+    * Amcrest Camera API: Added support for specific Units to link to Object Detection if your camera supports it. You can now create a Unit to get an ON when a human is detected, or when a vehical is detected and so forth.
+    * Amcrest API New Status and Display commands:
+      * setFontScale(0.1..2.0) control the size of the text displayed over the image.
+      * setChannelTitleVisible( true|false)
+      * setChannelTitleLocation( 34, 12)
+      * setChannelTitleColor( R, G, B, A)
+      * setChannelTitleBackColor( R, G, B, A)
+      * setUserDisplayVisible( index, true|false)
+      * setUserDisplayText( index, “the info to display”)
+      * setUserDisplayLocation( index, xloc, yloc)
+      * setUserDisplayColor( R, G, B, A)
+      * setUserDisplayBackColor( R, G, B, A)
+      * setLogoVisible( true|false) hide or show the Amcrest logo image overlay
+      * setLogoLocation( xLoc, yLoc)
+      * setLogoFilename( “osd.bmp”) your camera must support allowing you to change this or it will do nothing.
+      * setTimeDisplayVisible( true|false)
+      * setTimeDisplayLocation( xLoc, yLoc)
+      * setTimeDisplayColor( R, G, B, A)
+      * setTimeDisplayBackColor( R, G, B, A)
+      * setTimeDisplayFormat( “yyyy-M-dd hh:mm:ss t”) see the wiki link above for a table of valid format string entities.
+      * note that there is a limit to the number of overlays the camera can “blend” into the encoding video. Check the capabilities below to find out what the limit is for your camera. They may all be different. My doorbell cam can only do 2 at once.
+    * changed the logEvents() command to be showEvents() and it now shows the info in a window rather than just writing it to the log.
+    * changed logMotionRegions() showMotionRegions() which also shows the list in a separate window rather than just writing it to the log.
+    * showCapabilities() opens a window with most, but not all, of the capabilities of the camera listed. There are still some more to add
+    * There are a LOT of other things I can add to this plugin that could be controlled.  If you know of something else you’d like to be able to tweak in the cameras programmatically please let me know.
+  * **Scripting Dictionary:**
+    * NEW: the [[dictionary:unitinformation:enumeratedvalue|Enumerated Value]] verb now accepts an optional parameter “for” and will return the correct enumeration for the value that you pass or an error if the enumeration is out of range. This is especially useful in the ON script of a unit as you can now check the enumeration for the future value to see what it is going to be when the script is done running. The direct parameter of unit name is now also made optional and if you dont specify it then it will use the value for thisUnit making it easier to script these in a units on or off script. For example: **write log enumerated value for (future value)** would write the enumerated value for the new value being passed to the On script.
+    * NEW: The [[dictionary:unitinformation:changefuturevalue|change future value]] verb now also accepts enumerations just like the regular set value verbs so you can issue a change future value to “high” instead of just knowing what the numerical value is.
+  * **Xtension UI:**
+    * New: Each unit will get a new Unit Property called Created with the date the unit was created. You can add this to any List view by control clicking in the headers and selecting create custom column. Then you can sort lists by the date the Unit was created and not just the last activity date. For new Units this is set as they are created and then never changed. For existing Units the date is taken from the creation date of their folder within the database. This seems to work pretty well for most units most of the time, but there may be a date in the past where you restored a database or otherwise performed an action on it that would have reset those dates. This is still the best I can do but keep in mind that older Units may not show the date they were actually created, but the last time you zipped and moved the database or something like that.
-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.
-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.
-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.
-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.