Matter-enabled devices in AM?

[st...@marshallarts.com.au]

Hi all - but mainly Mike,

I've recently become aware of the "Matter" ecosystem for connected homes, and have been delving into it a bit.  Looks interesting, although I'm a bit wary that it is promoted by the big players like Google, Amazon, Apple etc etc.  But also a lot of smaller ones.  In particular I've been trying to find some sort of SDK (ideally in Java) that could be used to communicate with Matter devices locally, i.e. on my own network.  I haven't managed that yet, and I'm definitely not finding it easy to find a way through the forest of stuff that is on the web about Matter.

Mike, I'm sure you are well aware of Matter, and probably more aware than many of us about where it is at.  It is very unclear to me just what state it is in at the moment, although there are certainly quite a few devices available for purchase which claim to be "Matter-compatible", even here in Australia.  AM can currently support lots of branded devices - Lifx, Tuya, Sonoff etc etc - is there any thought that it might be able to interact with Matter devices at some stage?  I don't see any mention of it on your website (yet).

I have a few of the TP-LInk Tapo P110 smart plugs, and have found a Python package that can drive them outside of the Tapo app (someone reverse-engineered the protocol).  I realised recently that there is a Matter-enabled variant of this plug called the P110M.  I've grabbed one to try, and the Python code still works on it, so it must be bi-lingual so to speak.  I'd love to find a library or something that would allow me to cut some code to control them myself - will continue the search.  Using Matter would be far better than relying on a reverse-engineered solution.

[sergey]

Good question Steve!) As I know the only ESP32 compatible library exist for Matter from all esp-family devices. Mainly due to limited memory resource in esp8266.

So if the "Matter" is really matter for Mike we'll see moving toward ESP32 that is really good thing  )) 

I've never interested with Java , but I'm sure there are plenty of examples for C++ and ESP32 , moreover I heard the  espressif   makes their own "Matter" fork. https://github.com/espressif/esp-matter

Having that you can write your own device that is "matter" with AM gateway.

[st...@marshallarts.com.au]

Thanks Sergey, will have a look at that Espressif repo.  But I think it will be aimed at people who want to build Matter devices - I don't want to do that.  I'm happy to buy the devices, but I just want to know how to communicate with them, i.e. request data or send commands to turn on/off etc.  And I want to do that locally of course, with no cloud involvement.

[sergey]

Yeah Steve, I understand what did you mean , but my thought was that unless Mike add "Matter" support in AM Server , you can do it self made by AM-Matter gateway...
I've got several controllers , mostly Ethernet based, that definitely won't never support by AM server natively , so I've run esp8266 AM-compatible devices that works as their managers ,therefore I can manage these controllers over AM Server. Thanks Mike for patience and support..in their development))

[Mike P 4 MPP]

Matter is a bit of a nightmare, there's a lot of security function that looks similar to homekit that IMO is totally overkill at home.  I can see where they're going with it, and it would be viable to use in a commercial environment.  I won't be trying to implement it in MPP,  it's good enough for our use at home, so as Serg says a bridge would be needed if you went that route.

For AM there's a google library that support mesh.  I've looked at it and there's a lot of registration needed with google to make it run - my suspicion is that google does the authentication in the cloud and communicates with the matter devices to get connected, but I'm not certain about that yet.  They connect to a "fabric" of which you can have multiple for difference fabrics running in your environment to keep them separate.  To me it looks a little "designed by committee" to fit every imagined deployment.

I'll pick up some tapo devices for both that and the python integration when they come on sale, right now they're too expensive for something i don't otherwise need...

[st...@marshallarts.com.au]

Thanks Mike, good to have the "official view".  From what I've seen so far, I agree - Matter does seem inordinately complex.  And I'm dubious about Google's motives with it too, even if it does include local APIs.

And while I'm typing, I have finally assembled my test gizmo for messing with IR, and flashed it with MppIRRC6.  It's a Wemos D1 Mini with the Wemos IR shield, and comes up and runs fine, but it doesn't seem to be seeing much from my aircon remote.  Once or twice I've seen a message about "wrong protocol" or similar, so I'd like to rebuild it for detecting Fujitsu codes rather than RC6, but I'm having a lot of trouble finding all the ancillary files needed - there seem to be many levels of #includes and it's not clear to me where to find many of these .h files.  It seems I can't just point the Arduino IDE at GitHub, so is there some defined strategy for this?  I could be wrong but I think the Github repo mentioned in the sources may have changed somewhat too.  Sorry if this is a dumb question, but it's quite a while since I worked with the Arduino IDE and last time it was all fairly easy.

[sergey]

Could you briefly describe your final goal ? Are you trying to get the Fujitsu aircon to be managed over AM?  If yes , the only interface it has - IR port ?
What I tried that area - having managing Mitsubishi Mr. Slim  aircon as AM thermostat ... , but the Mitsubishi is the industrial standard system and doesn't have IR remote , only "wall-wired" and RS232 . Unfortunately the "hot summer" in my area is so short , that I decided to postpone the project till the heavier climate changes and moved towards heating system development.

But there is nothing special for installing libraries from  GitHub  for Arduino IDE - multiple ways , what I used to go is manual - you just download the achieve and unzip it in common library folder , but more conventional way is - installing library "Sketch->Install library->Install zip. library" preliminary downloaded from Git.    

[Mike P 4 MPP]

Yep, that's what I recall as well, use a zip file with the arduino installer.  I use eclipse so I'm not very experienced with the arduino ide though.

Usually what I do is find a sample that's close to what I want, build it as they instruct in the sample, then move the bits I need into my own version.  If you downloaded their entire package and get includes not found (maybe do a file search to double check) then the problem is the path definition.  If you didn't get everything, github download I think there's a checkbox to capture all of the dependencies, though it might depend on how they defined them in the sample.

The (built in) libraries I use for MppIrRC6 are: EEPROM, ESP8266WebServer, ESP8266Wifi which are standard for MPP plus IRremoteESP8266.  Fujitsu_AC is in the list.  Once you have those attached MppIrRC6 should build properly and you can go from there.

'

Sounds like the receiver is working though which is good (in that it's receiving something), so yeah, the right protocol is needed.

[st...@marshallarts.com.au]

Thanks Mike, that's very helpful.

And Sergey - yes my idea was to see if I could control the Fujitsu airconditioner in the Mpp system somehow, so that it would appear in the list with all the others.  And yes, the only interface available is the IR (as far as I know, I haven't opened it up to look at what's inside :-)  ).  I did buy a device called a Sensibo Sky, which sort of does what I want - it's an IR controller which can be driven via the cloud, and it can speak the Fujitsu's language (and many many others).  It does work, and quite well, but it's the cloud part that bothers me.  I believe it's built around an ESP8266, and I've even seen something online about someone re-flashing it with their own firmware.  It has its own app of course, but Sensibo DOES publish a cloud API, so I have my own Android app firing requests off to the Sensibo cloud to do things, and that works reasonably well too.  But I would much prefer to be able to do this on the local network, without the cloud.  That's why I'm looking around in this area.  It's certainly not something I NEED to do, just something to stretch my brain a bit!  And it's always fun to figure out how things work.

[sergey]

Yeah... Afraid the Sensibo is not the thing I could help you . Frankly I didn't poke around that well, but from my friend I heard the Sensibo need in internet connection for command system download accordingly the aircon choice, and because it is built on ESP32 - not so much memory there. So -  rewriting will only help if you can parse Fujitsu command set. Everything other , include API would only work with internet connection to the cloud.  But if I not mistaken  - after it has setup the hardware , it won't go to the cloud and you can use API scripts or command to the Air for your air-condition management locally and even close gate to the cloud in router. Look at Github - there are plenty of different gateways for Sensibo. Pretty sure it can be managed by MQTT and Mike sort of wrote about Mqtt support too.

[st...@marshallarts.com.au]

As almost always happens when I start looking at places in the AM Server world that I haven't visited for a while (or ever), I discover that Mike's system is way smarter than I thought...

I've just set up a couple of EventDevice entities, one to switch on the airconditioner and one to switch it off.  They send the required HTTP requests to the Sensibo cloud, and it all works beautifully - of course.  One question - it would be nice to be able to set the STATE property of an EventDevice based on the reply from the HTTP call, inside AM Server.  When called with a switch on/off request, the Sensibo cloud responds with quite a detailed JSON object that indicates whether it was successful, plus lots of current airconditioner state info.  I know I can get AM Server to save the response from the HTTP call in the MESSAGE property of the EventDevice, but is there a way to tell AM Server to use a property in that response to set the STATE of the EventDevice?  If I could do that, then I think I could have just one EventDevice for the aircon which I could toggle, and  it would correctly reflect the current state.  So I could control it completely within the Mpp system.  I know I'm not avoiding the cloud, but it's a start...

[Mike P 4 MPP]

If you're ok to use the cloud for it, the easy way to integrate it is through SmartThings (cloud).  I only have a few device types supported for smartthings integration but I wouldn't mind adding one for AC control as a thermostat (if I haven't already, I can't recall).  Another choice would be IFTTT using webhooks and the IFTTT integration in AM.

For what you're trying to do with events locally there's custom "HTTP device" that might work depending on the function you're trying to get working.  You specify the fetch url for state and the post url for actions and use them as regular AM devices.  The response parser lets you find a true/false/off/on property in a json response to find state, it supports simple nesting.  For anything more complex tasker might be a good option, you can do a lot of work in tasker to make url calls and to adapt responses to the AM interface locally.

[sergey]

I'm sure Mike will suppose  with the best solution , but as far as I know - there are two Events might be triggered for successful "sendHttp" command or not, so ... you could adjust Event to trigger on , for instance, succeeded running "Aircon On" , and in that event you can set the state of your virtual device "aircon"..  

 Otherwise for parsing JSON response and setting "states" you will be needed running your own device, that is also not a big problem...

[st...@marshallarts.com.au]

Ah thanks Mike, another path I haven't yet trodden!  Will definitely explore the HttpDevice feature.  I think I'm going to have to put up with using the cloud for this one, I haven't (yet) found any way to talk to the device locally. I posted a feature request on a TP-Link forum about a published API for the Tapo devices - not very hopeful, but you never know.  If it happened I'd be looking to absorb them into the Mpp system too.

[st...@marshallarts.com.au]

This is brilliant Mike, I reckon the Http Device is EXACTLY what I need.  I've set one up and it is recognising the current state via the GET url.  I was able to switch the AC on with the SET url, but when I try to switch it off it fails with a "400 Bad Request".  So my question is - does the substitution of the &state token happen in the request body as well as the url itself?  That's what I was assuming.  My request body is  { "acState" : { "on" : &state } }   and the Sensibo wants the "on" value to be either true or false.

The request is a POST, and doesn't have any substitution in the url, only the body.  I've looked at AM Server's log but it doesn't show me exactly what it has sent.  It seems weird that it can turn it on but not off.  Any thoughts welcome.

[st...@marshallarts.com.au]

Sorry, further info - it is now failing in both cases, i.e. I cannot switch it on or off.  No idea what happened the first time, I haven't changed anything.  To investigate further, I changed the body and replaced the &state token with "true" (without quotes), and it switched on fine.  So I think the substitution is not being applied in the body.  If that's by design, then how do I vary the body for the switch-on and switch-off cases?  Very close now....

[sergey]

What I have encountered with -sometime  case sensitive design of rules confuses.  Have you check that this is "&state" or "&STATE" ?

[st...@marshallarts.com.au]

Good thought Sergey, but yes I have tried both.  If substitution is happening in the body field, I'm wondering if it is substituting "on/off" instead of "true/false", but I can't see what it's doing.  The Sensibo cloud requires true/false.

[Mike P 4 MPP]

Not substituting state in the body wasn't by conscious design, just not something I'd done in the code yet (the devices I've used it with so far accepted on/off changes as a URL parameter rather than needing a body).  It's an easy update, released as beta 17.3.1, usually available in 24-48hrs (depending on google).

[st...@marshallarts.com.au]

Excellent, thanks Mike.

[st...@marshallarts.com.au]

And by the way...

You might already know all this, but if/when you get around to acquiring a Tapo device or two to investigate, it's the ones with M on the end of their model number that support Matter.  The P100/P100M is a simple switchable plug, the P110/P110M is switchable and also does energy measurement.  I'm sure the M variants can still use the normal Tapo protocol as well as Matter.  I have 3 or 4 of the P110s so they are of most interest to me.

One useful thing that TP-Link did a while back was to unify the management of Kasa and Tapo devices into one app, the Tapo app.  One less app is always good!  Cheers.

[st...@marshallarts.com.au]

I have seen the new version and installed it on my AM Server tablet.  Unfortunately there is no visible change.  I still get the 400 Bad Request error when I try to change state on my HttpDevice.  When I look in Android settings/Apps and look at the details for Automation Manager it says it is version 17.3.1, but I can't see anywhere in AM Server itself that indicates what version it is.  I had subscribed to the beta option and it came through just like a normal update.  Do I need to do any more than that?  Is there anywhere apart from the log where I could look to see what's happening?   I did restart the tablet, and I cleared AutomationManager's cache.

The URL for my POST action is:

https://home.sensibo.com/pods/xxxxxx/acStates?apiKey=yyyyyyyyyyyyyyyyyy&fields=acState

The body of the request is     { "acState" : { "on" : &state } }

where xxxxx is the ID of my specific Sensibo device, and yyyyyyyy is an API Key which basically authenticates me to make the request.  They are passed in the URL, along with the fields= parameter, which tells Sensibo that I only need the acState field to be echoed back in response.  Without that the response is a lot longer.

If I send this request with the right values in it for xxxxx and yyyyyy, and with either true or false (without quotes) in the body where &state is (from a little Java program I knocked up for testing) it works fine.  The response that comes back from the Sensibo cloud looks like this:

{"status": "success", "result": {"acState": {"timestamp": {"time": "2024-07-18T05:45:52.257839Z", "secondsAgo": -1}, "on": true, "mode": null}}}

[sergey]

Following your project with interest , Steve!  Because I have to still figure with my Mitsubishi MrSlim too . Hope Mike will help to sort it over. But if I were you , I'd try separate processes :

1. Create flag-device "Aircon" 

2. Run the rule "Aircon On" where 

- send particular http command   { "acState" : { "on" : true } } and check http response - if "ok" (code 200) than:

3. set the  flag-device "Aircon"  to on status. 

Similarly wind up rules for switching it off .

This is kind of excessive approach , but in future you might be need in more tricky command to aircon , not only on/off. 

And even despite I always been criticized by Mike for that - I'd run a private ESP8266 device for parsing all these commands and responses , setting temperatures and showing the status.  

The code I'd take from Protocol.ino , or similar.

Ready to help with code!

[st...@marshallarts.com.au]

Thanks Sergey, another door I haven't opened before - Flag Devices!

Yes that does indeed work beautifully, so it is definitely another way to approach this, and no substitution of values required.  Amazing!  Thanks so much for your input.

Every time I go somewhere in Mike's system where I haven't looked before, my respect for this system increases even more.

[st...@marshallarts.com.au]

Just thinking about this a bit more - the Flag Device's switch changes state by itself when tapped, so I don't need to set its state if the command succeeds.  If it doesn't I guess I could set its state back to the opposite of what has been requested.  So, if it was switched ON but the request failed, I'd set it back to OFF.  BUT - if I do that, won't it trigger the rule for the FlagDevice being switched off?  That could end up in a runaway loop condition where AM Server disappears into a black hole!  Or is it smart enough to avoid this?  This makes me think the HttpDevice is a slightly better option because I can tell it how to get the physical device's state, so the software device should match the real world all the time.

[sergey]

The  Flag Device - just a device with the state , that might represent for you if the rules was successfully finished or not, you needn't to tough it.

Sorry for my inattentiveness - that I didn't mention that in mind mind there are two devices - the one you tapping and it trigger the rule and the second - is for state only. The pros is - you can run http rule with particular command and in that rule you can run the event for good response (200) and for bad response (f.e 400). Definitely the http device is better if it works...
What I supposed is the workaround method when "&state" doesn't work )

[st...@marshallarts.com.au]

Aaaah I see what you mean now - two software devices working together.  That's a very creative solution, but I can imagine it working.  I will see what Mike comes up with regarding the HttpDevice, but there are lots of options to think about.

[Mike P 4 MPP]

Looks like it's missing a ";", the body should be "  { "acState" : { "on" : &state ;} }  "

[Mike P 4 MPP]

Right, Serg's suggestion can work well in a complex situation.  What I would use in a case like this would be a http custom sensor (like you already have but no switch), and two "Event" devices, one for on, one for off.  The sensor would poll the API to find and track the state.  The events would be used in separate rules where the action would be to SendHTTP the appropriate url to change the AC state.  It's easy to control the AC using rules, if you want manual control I'd use a persistent "Flag" with a switch widget where you get to pick on/off when you touch it, the rules triggered by that flag changing state as well as the events.  As Serg mentions, you can get fancy using the HTTP failure case to resync things.

There's a newish "composite device" that might be useful here for a prettier widget - I use it to manage my remote door lock which is controlled by a MppSwitch (off.on) and a zigbee sensor for the lock state.  Here you'd use the sensor with the above Flag for on/off.

I would avoid the external MppProtocol device in this case, it's probably better to do any complicated protocol conversions on board the AM server phone using Tasker.  If the MppProtocol device was used to contact the AC API directly (so always between AM and the AC in and out) it might be an interesting choice, but HTTPS is a bit complicated for an ESP8266 and I haven't played with it.

[Mike P 4 MPP]

Yep, I know about the tapo models, and I have the app too (I use it for their cameras but it did find all of my kasa devices).  Kasa is still the primary over here so there's not many choices for tapo - the P100s and P110s are being sold in 4 packs, puts them over the top for me...  The cameras are good, they support RTSP.

[st...@marshallarts.com.au]

Thanks Mike, mea culpa by the look of it.   Is that semi-colon a JSON syntax requirement?  The Sensibo API documentation does not show semi-colons in any of their examples, which I guess is why I didn't put it there.  And the weird thing is that it works fine in my little Java test program with no semi-colon.  That's running in Windows, so is this operating-system dependent somehow? It's almost like the error is happening before it even gets to the Sensibo cloud - I'm having trouble getting my head around this (nothing unusual about that!).

Anyway, I have added the semi-colon, and it now DOES switch the AC on and off, quite reliably.  But after it does so, AM Server comes up with a Socket Timeout exception. This is when I tap the switch in AM Server itself, on the page showing the list of devices.  If I do it from AM Remote it doesn't pop up in AM Server, but does show in the device message.  I guess that could be some subtle timing thing with the Sensibo cloud.  And even more weird, if I put a space between the &state token and the semi-colon, it gives the 400 Bad Request error and doesn't work!

You and Serg have given me plenty to think about.  Lots of investigation coming up for me.

[Mike P 4 MPP]

The ";" is the substitution format for AM, it's "&variable;".  There should be a "Substitution" button when you edit the body that will show you a list and fill it in for you.

Usually a socket timeout is if the remote doesn't respond.  Since it's an HTTP request the API host usually closes the connection, could be the API doesn't for some reason (perhaps they allow multiple commands in one connection).  If you have windows (they may have it for linux or iOS as well) there's an app call "PostMan" you can use for free - it's a good way to test the outgoing API calls and to see what it's doing for a response.

I'm not too keen on adding http flags to requests (it's too complicated for a UI) but if you can confirm that is the problem I could be convinced to add a flag for autoclose.

[st...@marshallarts.com.au]

Aaah, ok, the penny has dropped, I get it, thanks.  I'm not overly concerned about the timeout thing - if HTTP hosts can behave in different ways we can't expect AM Server to handle every imaginable situation perfectly.  The whole reason for doing this is so that we can turn the AC on when on the way home from somewhere, using AM Remote, just like we can with lights.  That works (and looks) perfectly fine, so I won't be trying to convince you of anything.  I have a working solution, and might be able to optimise it further.  You should have a link somewhere for a Buy Me a Coffee or Buy Me a Beer - I reckon I owe you one!  :-D

Thanks again for the prompt assistance.  And thanks again to Serg too.

[Mike P 4 MPP]

I'm looking at the code, and seems a bit weird that you'd get this error.  Can you have a look in the log after send a request?  If the request fails AM will retry a few times which is probably not optimal.  The read timeout is 10s which I think gets reported as a socket timeout.  The connect timeout is 10s as well but the request would not work at all in that case.  AM will close the connection if it gets a good response or after each timeout.

My concern here is that the server may not be responding at all, in which case you might want to revisit the syntax of your request.  They might have a log you can check, or you might want to temporarily add events to the "successful" and "failure" part of the SendHTTP action to see what's happening (you'll see which event is triggered in the log).

[st...@marshallarts.com.au]

The timeout dialog pops up within 1 second from tapping the switch in AM Server. Here is a screenshot of the log just after doing a state change.

[Mike P 4 MPP]

Oh, right, this is the custom http device, I was looking at the SendHTTP code. 

Here the timeouts are 1s with no retries (I was anticipating they'd be used internally) which is probably a bit short for an external call.  I'll do a beta 17.3.1.1 with a longer timeout, let's see if that sorts it - it's likely too quick for a round trip to a cloud server, esp if the server doesn't respond until after it contacts the AC.

[st...@marshallarts.com.au]

It's saying in the log that the requests "failed" but they didn't - the state definitely changed as requested.  Does AMServer just use the status code = 200 to determining success or failure?  I've just run this request again in my test Java program (on Windows) and the response code is definitely 200.

[st...@marshallarts.com.au]

Yes that makes sense - there will be 3 or 4 trips back and forth - 1 from AM Server to Sensibo, 1 from Sensibo cloud to Sensibo device, 1 response from the device (probably) and then the response from the cloud.  And I guess you could put any other name in place of Sensibo for other devices like this.

[Mike P 4 MPP]

Yep, it's looking for 200 for success, it'll post the RC in the log if it's not, or the exception if it's a timeout.

I increased the connection and socket timeout to 10s each.

[st...@marshallarts.com.au]

And after getting the 200 response to the POST request, does AM Server then call the GET url to verify current state?  With Sensibo it could verify it from the POST response but I realise that other systems/devices may not work that way.

[Mike P 4 MPP]

Yep, exactly, I don't have a way to specify how the response should be parsed so 200 indicates success and the new state is found a followup fetch.

[st...@marshallarts.com.au]

It all makes perfect sense.  Bedtime here now, have a good day.   B-)

[st...@marshallarts.com.au]

I must have been dreaming about this last night...

It occurs to me that if you wanted to, you could add a checkbox indicating "Use Set response for state confirmation", and if it's checked, enable another text field like the one for the Get url, for how to drill down into the response body (because they could be different, of course).  So it could save another HTTP call.  But probably better to keep it simple, and leave it as it is. 8-)

[Mike P 4 MPP]

LOL, after a restless sleep when I wake up with a solution I want to charge for those hours :).

Right, it would be possible, but this adds quite a bit of UI work as well as being a PITA to test so I decided the post fetch was enough when I built it.  If we run into an API where it's absolutely necessary I can revisit and reuse the same code use in the fetch url part of the API.  The pos fetch should be reasonably quick and does properly confirm success.  Even if there were a failure AM does keep trying it starts with a fetch first, and will stop only when the state change is successful.

[st...@marshallarts.com.au]

Yes, all good.  The update has appeared already and I just installed it.  It's all now as smooth as silk, well done.

[st...@marshallarts.com.au]

The whole cycle for Sensibo seems to take around 2.5 to 3 seconds.

[st...@marshallarts.com.au]

Sorry, one more question then I will leave you in peace...

If I send an HTTP request to AM Server from another device, to tell my HttpDevice to change state, at what point in the cycle does that other device receive the response with statusCode=200?  It seems to be happening earlier than when the whole cycle is complete.  Not a big deal, would just like to understand the mechanics of it.

[st...@marshallarts.com.au]

I should add that I'm directing the REST call to AMServer/devices....   I note that there is also a URL for AMServer/webdevices....   Maybe I should be using that??

[Mike P 4 MPP]

Bit of a escher-esq type question :).  AM, MPP, and a lot of the devices with an HTTP API report 200 when the action is accepted.  Arguably this is more REST-full, but I literally mean arguably :).  A REST post or put action may not complete immediately, so AM defers to following up with a fetch.  It'll retry the action every few seconds until the state/action is reported as changed/complete.  A few (like kasa IIRC) report state in their response so AM will clear the request immediately if possible, but it's device and action dependent and the custom HTTP device is meant to handle the generic case.

I do use custom HTTP devices myself to talk from an AM client to problematic devices managed by an AM Server.  For example, battery powered MPP devices only reliably notify a single AM Server - the multicast UDP update can be missed by other AM instances (esp if disconnected).  So an AM client is better querying the AM Server where the state/value has been cached.  I have a few AM servers around the house running on dedicated tablets as status displays and this is an easy way to share temperature values from my main AM server.

Speaking of which, I recently built an MppHub device that is the proxy to AM for battery devices, works as a cache/fanout for MPP battery devices so also solves this particular problem.  Not sure I published it yet, if anyone needs it let me know and I will do so.

Makes sense, 2-3s is a good cloud response time but would definitely be marginal for the 1s timeout I was using.  The tradeoff is tolerance of the API response speed vs how quickly problems are detected/reported.

[Mike P 4 MPP]

Ha!  So much for the last question :).  This will definitely be it for me tonight though :).

In the custom http device there's a button to fill in the request urls for a target AM server - it builds urls against that same REST API.

[st...@marshallarts.com.au]

Well!  A bit of a can of worms - arguably!  ;-)

So there must be a definite reason for sending requests to the /webdevices branch of the REST api vs the /devices branch, yes?  There must be some difference or I presume it wouldn't be there.

And since you mention Escher - are you by any chance a fan of Douglas Hofstadter's amazing book "Godel, Escher, Bach: An Eternal Golden Braid"?   First published in 1979, and one of the most remarkable books I have ever read.  I reread it every few years and always get more out of it - there is so much in there.  I'm guessing you are a fair bit younger than me (I'm 74), so in case you haven't heard of it - Hofstadter is a professor of mathematics and cognitive science, but has wide interests in all sorts of things.  The book is a hypothesis (argument?) that the music of J S Bach, the mathematical theorems of Kurt Godel (specifically the Incompleteness Theorem from the 1930s) and the strange paradoxical etchings of M C Escher are in many ways just different views of the very same thing, which might be described as "how the world works".  It has incredible breadth and incredible depth, it's an amazing intellect at work here. I've come across very few people who have even heard of it, let alone read it.  When I try to describe what it's about, most just glaze over.  Anyway, it might just be something that floats your boat.  I concede that it is a very big read, but (I believe) worth the effort.  Hofstadter has several other books too, my second favourite is "Le Ton Beau de Marot: In Praise of the Music of Language", in which he dissects the process of language translation to an incredible degree, plus much, much more.

[Mike P 4 MPP]

Yep, /devices is the main API, the /webdevices extension separates control - /devices put "state" tells AM to update the state of an attached device, e.g. a kasa switch, where /webdevices is an extension to put "state" and/or "value" to tell AM to update it's internal state of a web device (with no other action).  I don't have a strong argument for making them separate other than I was extending some code that did take action on a put in the base function. 

This took a sudden turn to nerdy :).  In fact I do have a copy of Hofstadter's book and liked it a lot.  It's been a while since I read it (or any analog book TBH!).  I'm thinking maybe it's worth a re-read now either to better prepare for the fast approaching "singularity" before we go obsolete, or perhaps it could put to rest the theory that it's more likely than not we're part of a simulation :).

[st...@marshallarts.com.au]

Oh yes, it's Nerd Central here.  If you have GEB, I'd speculate that (like me) you might even have D E Knuth's classic series  "The Art of Computer Programming".  And of course the 1978 edition of Kernighan & Ritchie's "The C Programming Language" is almost de rigeur!  From what I see online, they can be quite valuable nowadays.  8-D

I don't think you'd find any of Hofstadter's books in digital form.  This guy is such a control freak that he personally chose fonts and personally laid out every page of all his books, even changing sentence length/structure so that everything looks "right", whatever that might mean.  He must have driven his publishers nuts.

Thanks again for all the help, I look forward to hearing something about Tapos at some stage.  But I won't be surprised if I don't. 

[Mike P 4 MPP]

LOL!

My K&R fell apart a long time ago, no need to replace with the advanced editors and the internet.  God I hated C++ though, what a bastardization of a language, like it was designed using #defines in a C compiler.  I don't think I ever anything from Knuth, I was EE and I suspect we were taught a less mathematical approach to programming - the texts I had were pretty focused on the application of algorithms, very little theory.

[st...@marshallarts.com.au]

It's good to hear someone else say that about C++, I've never liked it either so I absolutely agree with that summation.  It all seems very fragmented to me, and I really struggle to work out what's actually going on.  I guess familiarity/experience would help, but I never adopted it so I don't have either!