ztalbot2000/homebridge-cmd4

Cmd4 V8.0.4 is updated to recognize node V24. Note: No testing was done other than making sure the package installs and runs. This is just bare minimum support as I do not intend to continue with any major CMD4 development. take care, John Talbot

Minor change as title suggests

Hi all, This minor change fixes a bug in homebridge v2 where old accessories were not being deleted. Thanks to Wong for the fix. It was the most elegant solution when I looked at different possibilities. take care, John Talbot

Hi all, Cached accessories and those not defined in your config.json no longer need to be explicitly removed as the homebridge plugin template skips over them. The result was it looked like accessories were being added and removed, but they really were not. If anything, the last known state over a restart was lost of your accessories. This has been corrected with this release. ttyl, John Talbot

Good day fellow homebridge users Cmd4 v8.0.0 makes changes that support the upcoming homebridge v2. Their release deprecates a few device types, namely bridging devices that I'm pretty sure nobody uses. There are a couple of associated characteristic settings that they also deprecated. The only one I found odd was the characteristic named "category"; not that HomeKit actually used this recommendation to change the icon. take care, John Talbot

Hi all, Please note that in the upcoming Cmd4 version 8.0 only Platform defined Cmd4 accessories will be allowed. (No worries. This is probably everyone). This is because of <a href="https://developers.homebridge.io/#/">Homebridge deprecated templates</a>.This will also make homebridge-ui easier to implement. In short this is allowed: ```json "platforms" : [{ "platform": "Cmd4", "accessories" : [{ "type": "Switch", ... ``` This will not be ```json "accessories": [ { "accessory": "Cmd4", "type": "Switch", ... ``` <BR> Now onto the good stuff ...<BR> Cmd4 version 7.1 now supports the following new accessory types: <UL> <LI>AccessCode </LI> <LI>FirmwareUpdate </LI> <LI>TapManagement </LI> <LI>WiFiTransport </LI> </UL> <BR> Cmd4 also now supports the following new characteristics: <UL> <LI>AccessCodeControlPoint </LI> <LI>AccessCodeSupportedConfiguration </LI> <LI>AirPlayEnable </LI> <LI>CharacteristicValueActiveTransitionCount </LI> <LI>CryptoHash </LI> <LI> FirmwareUpdateReadiness </LI> <LI>FirmwareUpdateStatus </LI> <LI>HardwareFinish </LI> <LI>MetricsBufferFullState </LI> <LI>MultifunctionButton </LI> <LI>SelectedDiagnosticsModes </LI> <LI>SelectedSleepConfiguration </LI> <LI>SiriEnable </LI> <LI>SiriEngineVersion </LI> <LI>SiriLightOnUse </LI> <LI>SiriListening </LI> <LI>SiriTouchToUse </LI> <LI>SiriTouchToUse </LI> <LI>StagedFirmwareVersion </LI> <LI>SupportedMetrics </LI> <LI>SupportedFirmwareUpdateConfiguration </LI> <LI>TapType </LI> <LI>Token </LI> </UL> Enjoy,<BR> John Talbot **Full Changelog**: https://github.com/ztalbot2000/homebridge-cmd4/compare/v7.0.3...v7.1.0

This is a very minor fix as nobody has used this feature in a long time. If you redefine your characteristics properties they must be formatted like: ```json props: { currentTemperature: { maxValue:32, minValue:1}, targetTemperature: {maxValue:32, minValue:1} } ``` There was a bug that predefined the object and this feature was not documented properly. Also a unit test was implemented to test if the actually properties were changed. Note: while Cmd4 allows you to change the properties and Homebridge accepts this; That is not to say that the HomeKit GUI will respect them.

### v7.02 Change for AdvantageAir This change is for the AdvantageAir plugin only which uses Cmd4. It puts double quotes around the accessory names instead of single quotes. It allows them to put single quotes in their accessory names; However they accept the responsibility that moving away from single quotes means the shell can interpret the names within.

Hi, The reason for the major version numbering update was to for deprecation warnings to throw an error. These warnings have been there for years. Otherwise there was just one major bug fix for an accessory not going unresponsive and not showing it recovering afterwards. I don't have much time to play with homebridge lately so please be patient if you find issues. The beta of the above fix has been available for months and people have been using it. take care, John Talbot

there was an annoying update message left in that has been removed. a test case was created so this cannot re-occur. v7.0.0 documentation was updated

The reason for the major version numbering change was for some deprecation warnings to be removed and to now throw an error. A bug to fix accessories not going unresponsive was resolved and now a "Get" retry count can be set, the default is zero (No retry)

Hi all, &nbsp;&nbsp;&nbsp; I hope you all enjoy Cmd4. I've updated it to reflect some new Accessories and Characteristics supported by Homebridge. Most of these involve TLV8 (binary) values, but since Homebridge has them so should we 😀. I'm proud of the way I wrote Cmd4 in that adding new Accessories and Characteristics are as simple as updating the library files, so no code changes required 😁. This is why only the minor version update bump. The New Accessories are: > AccessoryMetrics AssetUpdate Assistant AudioStreamManagement Battery CameraRecordingManagement CloudRelay DataStreamTransportManagement NFCAccess SiriEndpoint ThreadTransport The new Characteristics are: > AssetUpdateReadiness SupportedAssetTypes ConfigurationState, NFCAccessControlPoint, NFCAccessSupportedConfiguration SiriEndpointSessionStatus ThreadControlPoint ThreadNodeCapabilities ThreadStatus ThreadOpenThreadVersion <u>Bug fixes</u>😢 Bug https://github.com/ztalbot2000/homebridge-cmd4/pull/130, linked accessories not accesible after restart ([aeab5a40](https://github.com/ztalbot2000/homebridge-cmd4/commit/aeab5a40340631910ae6ac19f9af8453f46faa55)[] Thanks to crbyxwpzfl for noticing this one! The bug probably existed for as long as LinkedTypes was added. Unit testing over restarts has always been difficult so I thank crbyxwpzfl very much for reporting it. On a side note, if you are wondering about Cmd4 support for Homebridge-ui, I'm slowly, very slowly, working on it. My thoughts were to auto generate the schema based on the Cmd4 Library files. The dilemma is all the options Cmd4 supports and the limitations of the JSON schema format, coupled with homebridge-ui only supporting up to v6. That is not really an excuse, but hey this is all gratis anyway. I have not forgotten about it though! Take care, John Talbot

Hi all, There are three minor changes, one to fix FakeGato graphing for bug #124 The second resolves a constant that had a dangling underscore. Finally there is a possability to try a different WoRm queue, being WoRm2 that might unclog large scale Aircon. They will test this out.

v6.0.4 Fixes a bug with LinkedTypes not using global Constants v6.0.3 Simplifies the schema for the upcoming Homebridge-UI integration. You may need to adjust your config.json accordingly, but highly unlikely. Sorry for the inconvenience. v6.0.2 Solves an issue for future homebridge-ui integration and schema display for possible constants. There should be zero affect. v6.0.1 Resolves bug#116. A day one bug where Cmd4 tried to validate the users state_cmd. This was never a good thing to do. When Cmd4 was first implemented, I tried to be considerate in allowing either lower or upper case key/value pairs. Unfortunately as Homebridge has evolved and to use homebridge-ui you require a config-schema.json which accurately describes the Cmd4 Schema. This is impossible to achieve when the key/value pairs can be either lower or upper case; Especially when Cmd4 supports so many characteristics and devices. To this end; Cmd4 Version 6 will be the version that prepares you for the change by *Warning* you that your config.json needs to be corrected. The duration of this preparatory stage will be pretty generous as I am still working on the config-schema.json integration with Homebridge-ui. I had to stop when it became evident what changes were required for Homebridge-ui integration. Here are the rules / changes: 1. No script changes are required. Cmd4 still sends: Get/Set <DeviceName> <Upper Case Characteristic Type > < value > 2. Constants are still fully capitalized. i.e. "statusFault": "NO_FAULT" or "category": "TELEVISION" 3. As before Device Types start with an upper case. i.e. "type": "Television" 4. Cmd4 directives and characteristics start with lower case: i.e. "polling": [ { "characteristic": "volume", "interval": 10 }] 5. For advanced devices like the AirCon, Queue types remain the same: i.e. queueTypes: [ { "queueName": "MyQueue", "queueType": "WoRm" }] Finally I tried to make the warnings very explict for what the correction should be and believe me; I am more sorry to have to do this than you may think. Thank you, John Talbot

I've tried to make Cmd4 faster by removing duplicate/unneccessary code. This helps stabilize the queue. As a note to those who use the queue, (Specifically Aircon). A "Set" to this device can only happen if nothing is happening at the same time. This is the purpose of the Queue in "WoRm" (Write Once Read Many mode). However it is impossible to detect if you are interacting with the actual device at the same time, thus momentary errors can appear from homebridge and Cmd4. The fact that Cmd4 tries to alleviate this Read/Write problem at all is significant. Many thanks to Mitchel Williams for all his efforts. Take care, John Talbot I hope you all enjoy, John Talbot

The polling queue becomes a little more intelligent in that 1) Only the latest setValue of a characteristic is used. 2) setValues are placed ahead of getValues 3) The stateChangezresponseTime applies to all characteristics of the devices queue 4) Queue recovery purges old requests, instead of them accumulating. As a note to all, A stateChangeResponseTime of Zero is the time taken for the script to run. Only devices like GarageDoorOpeners should have a stateChangeResponseTime to go between open and closed. The timeout is how long the script can take before being killed. Take care, John Talbot

Hi all, The Queue feature itself is meant for the Aircon, a special device which has many accessories in one device. Trying to talk to this thing has been nothing short of a never ending endeavour. The thought was that you could send all read characteristics at one (Burst), but the real fact is that when you interact with the device from outside HomeKit, Burst just confuses it more. This release removes burst, but alters the queue that if an error is detected, Reads (Gets) are delayed for 1 minute until it is expected that the device is no longer manually being interacted with. Hopefully this will do the trick. John Talbot

A fix for the possible inadvertent creation of a burst interval of zero, meaning it would run continuously. Changed related characteristics to an array for future handling of multiple related characteristics. Take care, John Talbot

The queued sanity timer was running every 12 seconds, not every 2 minutes.

For Queued polling, put Related "Get" into queue instead of calling it asynchronously. Fix Homebridge throwing error about invalid data which had an invalid return code anyway during Queued Polling. If you have some ideas about what else Cmd4 could do; Please let me know. I'd really like the config.schéma to be the next high priority, but all thoughts are welcomed. Take care, John Talbot

Good day to you all, This release delivers some much needed performance improvements with the churn as of late. More setup is done before the critical stage of adding the characteristics to the service and polling is no longer critically parsed during the "Set" events for related characteristics. The related characteristics are now defined per device as some some characteristics are optional in different devices or have no "Target" characteristic like Temperature Sensors compared to Thermostats. Take care, John Talbot

Myself and Mitch Williams have been hard at work on this feature for months in our spare time. Unfortunately he is the only one with an AirCon that really needs it, even though all could benefit from it in the end. My apologies for the many releases as it has been difficult to attempt testing without the device. We did do Betas for awhile and private branches, but it is a lot of extra work trying to maintain multiple streams. Thank you for your patience, John Talbot

I believe something went wrong with a branch merge. This fixes the priority polling queue timer not firing.

Priority Queued Polling is nice Sequentially, but is even better with Write Once, Read Multiple ( WoRm ). This means that only one "Set" can occur and nothing else, but multiple "Get"s can occur at a time across a device, which could comprise many accessories attached to a device; As is the case with an AirCon. If you continue to use Cmd4 as previously configured without Priority Queued Polling, nothing changes.

Correct a message of the number of staggered polling characteristics were displayed if PriorityQueuedPolling is also configured in another accessory. As well as ensure the stateChangeResponseTime was obeyed during PriorityQueuedPolling.

This release introduces Priority Queue Polling; A welcomed feature that resolves the issue of simultaneous queries to an accessory with a queued system. For any accessory with a Cmd4_Mode of "Polled" or "FullyPolled", by tagging the polling characteristics with a "queue": < queueName >, all requests of that characteristic will be put into a consecutive queue. The priority of the queue is given to all IOS requests and polling second. Further documentation of this feature can be found in the Cmd4 Developers Guide and from the Cmd4 Portal at https://ztalbot2000.github.io/homebridge-cmd4

This release picks up the new Cmd4 Capability of creating custom characteristics, documentation forthcoming. The update is mainly to fix a polling interval issue. Take care, John Talbot