Thanks for your feedback.
I guess that I'll have to spend some time on creating some "real" behaviour, with tasks, logic and the simulators.
I'll take some of your ideas and probably compiled them with other stuff.
Thanks for the tips.
I've made some further tests, and found more weird stuff:
I've selected just a single shutter for demo purposes, set the shutter to 50% on the device list, and turned on the simulator, with a 1 minute interval (tried with 2m, 5m, same result).
Every time the time elapses, and the simulator sends a random value to the shutter, coincidence or not it's always sending 50% or 49% for a long period... which leds the shutter to actually don't move.
Example with just one shutter selected:
Example with two shutters with 5 minute interval:
Please note that the 1/2/5 minute interval is just for demo and testing purposes, it's not going to be used in real situations.
Isn't it supposed to be sending completely random values?
That's a good question...
Paul and Jürgen, what's your hardware?
Btw, can anyone explain the release notes? They are a little bit vague:
I assume that the linux upgrade, will be to update the main OS itself. Shall we do it? Do we get any extra stability? Is it better to stand still and not do anything if our hardware is stable?
As for the KNX IP interface upgrade, what is it for?
I can also confirm that I had the same problem, coming from a 4.7.0 stable version.
The updated messes with the Back Color, in dozens and dozens of controls.
In my case, as the installation is relatively small, I was able to restore each Back Color item one by one (by selecting the messed ones). But I understand that on an installation with loads of stuff it can be very painful.
Last version before update: Stable 4.7.0
I forgot to include some items, like orientation of the tank, fuel type, and battery...
Just noticed now...
I've successfully extracted the info and created Http Device for the tank. Made it in a rush, so probably it may need some editing.
I'm attaching the file export, so you can adapt it to your needs.
I've set the GetToken to 86400 (24h). The API says that the token expires in 24h, so I've set it to 86400s, and the info extraction to 3600s (every hour).
I'm sending the devices set to false. Please set the devices to true, and insert your e-mail and password on the authentication (only on the first device created named as GetToken). If you want to see some results right away, you can force to send manually the commands, that's how I did it first.
The GetDevices command, lists all the devices available on the account
As there's only one device available, I've set the command "Device ID" token to the first device on the array: device
If you have other devices on the account, you need to change the index to the one you need.
If you only have one device, keep it device
If you have let's say 4 devices, and want to extract the information of the third, please change it to device
(The index starts from 0...)
Hopefully you can now change it and adapt it to your needs.
Perfect, that would be useful for testing.
I'll send you an email so you can send me that old account data.
I do some remote programming on some costumers running Jigsaw devices, and I don't have any problem (I'm using the stable 4.7.0 on every Jigsaw, I don't use any Betas on production).
Some notes:- For safety reasons, don't forward the default 3671 port (check the next note)- Forward a higher incoming UDP port (let's say 53671) to the internal UDP 3671 (to the Jigsaw IP address)- Don't forget to change to the correct port on ETS if you change it on the previous note- Don't forget to check the "Connect using NAT mode" on ETS connection
Thanks guys! I will try to use any of those devices.
If succeeded in the testings, probably I will have another integration available, with an awarded radio technology alarm system (no advertising yet, until a successful test is done). Probably it will take some days until I get the adapter, and the parts needed for the integration.
Customer support service by UserEcho