larryllix

If you want to use the resultant value in a program and be self triggering you need to do your calculations in an Integer variable and then transfer over to a State variable last line to avoid triggering the downstream program with every intermediate result of the calculation process.

yup if $sStatevar is not -99999 then $tempvar = %sStatevar $tempvar *= ratio else ---- You must have v5 to use fractional variables and ratio 230/801 Sent from my SM-G781W using Tapatalk

My mailbox lid gets up to about 54c on sunny days. It hasn't cooked yet though. Sent from my SM-G781W using Tapatalk

The 125V rating may be the North American receptacle configuration for that model.

Hey SG! If you have any Echoes or Google Home speakers, did you know you can install a skill for the Wireless Tags that you can just ask... ...Alexa! what is the TagName temperature? When asked the humidity, it replies "not available yet" but you will get the temperature back in thousandths of a degree. Nothing to do except hook the two accounts together on a prompted questionnaire.

Zwave appears to be the most popular protocol being sold and used right now. If you ever decided to migrate the polisy/IST994 it would be quite easily done and lives with WiFi devices mostly also.

Geeesh! You're right. This was a screen shot from a few years ago. Maybe I corrected that. hmmmm... I must have anew look now. Thanks! Update: I guess I worded that incorrectly. The "z" causes them to sort at the end of the constants "c" prefixed variables. I had so many variables to sort through in a small dropdown menu list I was trying to get some out of the way of every day programming needs. (reduce scroll hunting) I have since dumped the "z" subprefix as I have removed a few brands of RGBW bulbs and I only require constants for my MagicHome bulbs and strips now.

I wonder how the RF handles the mesh and hops. Just fire at random until you don't hear any interference, like Ethernet?

I guess the question in my mind then is: are the RF hops synchronised or not? I would think they may be synchronised with the powerline hops (each zero crossing) but cannot be using a simulcast technique. The RF frequency is too high to phase lock between devices, based on a 60Hz waveform zero crossing and would mostly be out of synch, confusing other signal senders. Powerline tech at 161 kHz? is obviously possible but different on 900MHz. Obviously Insteon RF is not self-reinforcing signals, as the powerline signals are but the RF may still be packet synced with powerline packets. Mesh packats need to not get ahead of each other.

That does seem to negate what I posted about needing synch on the RF. I believe it was in one of their white papers, but as I have stated before, white papers are usually only conceptual, and many fine details (like actual frequencies etc.) were not what what actually used in Insteon devices. Many tech companies do this to slow down hackers and protect their intellectual concepts. The other thing they do is release older software and then dump a later update on the market, as soon as some eastern country copies and releases it, Now the copy seems out of date, staying one step ahead. I also read somewhere in one of them that a dual band device only transmits RF when it receives a powerline signal and vice versa. I didn't believe that one from the moment I read it but...who knows?

Insteon RF is still based on 60Hz powerline frequency to synch the mesh simulcast....unfortunately. Divorcing the two would likely be a huge improvement in speeds but presents a lot of logical problems to be worked out.

I don't know if there is a 50Hz PLM but all devices would have to be 50Hz models also. Insteon is completely dependent on the powerline frequency. Signals are timed from a previous waveform and waveform period is critical.

Make sure you announce the PLM if you have one. People will be interested!! Sent from my SM-G781W using Tapatalk

The z in the name is so these sort to the last position order when looking for a variable in programming.

Nothing like self documenting code/variable names.

Make sure to set init-to to the same value so it never goes away. Also I found a bug that the last integer variable value gets cleared upon reboot. IIRC this was on ISY v5.3.4 so not likely fixed yet. I installed a dummy extra variable and it stopped disappearing. Sent from my SM-G781W using Tapatalk

I have inherited a 300 Zwave board. it has the LED and not sure if I want to break into Zwave yet but would like to test some things. IIRC it was v5.0.16c ? Do you remember the highest V5 version that can support it?

Gotta' love the way web pages constantly change their style. Just when you get familiar with something it changes locations again. Now feature buttons at the bottom of the pages where browsers sometimes can't even display them?

I have just started to try ISY on polisy. My LAN just became stable after a few years of fighting with three defective routers, so I have delayed trying to port ISY over to polisy until now. I didn't think it would get more complicated than this.

Not likely for hours Only the upgrade itself has been run. Here is what happening. I just noticed it complaining of a package not found. [admin@polisy ~]$ sudo pkg update Password: Updating FreeBSD-base repository catalogue... pkg: https://pkg.isy.io/FreeBSD-base/FreeBSD:13:amd64/latest/packagesite.pkg: Not Found FreeBSD-base repository is up to date. Updating udi repository catalogue... Fetching meta.conf: 100% 163 B 0.2kB/s 00:01 Fetching packagesite.pkg: 100% 107 KiB 110.0kB/s 00:01 Processing entries: 100% udi repository update completed. 399 packages processed. All repositories are up to date. [admin@polisy ~]$ sudo pkg upgrade Updating FreeBSD-base repository catalogue... pkg: https://pkg.isy.io/FreeBSD-base/FreeBSD:13:amd64/latest/packagesite.pkg: Not Found FreeBSD-base repository is up to date. Updating udi repository catalogue... udi repository is up to date. All repositories are up to date. process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock pkg: Cannot get an advisory lock on a database, it is locked by another process [admin@polisy ~]$

Thanks but it didn't change the errors reported. In addition: pkg: Cannot get an advisory lock on a database. It is locked by another process

When running the line sudo pkg upgrade I get a bunch of these errors. process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock process with pid 1877 still holds the lock Do I need to shut down ISY process first or how do I get my polisy to upgrade? pid 1877 is found as pkg upgrade owned by root

Need to contact UDI. They can be very generous with deals for people.

That will depend on how computer adept you are IMHO. PolISY is coming along quite well but there may be a lot of challenges. However, it sounds like a good plan but may drag for some time yet. You could consider contacting UDI and ask about a rebuild ISY and/or rebuilding your own PLM. One poster claimed he bought a USB PLM and swapped the board successfully. Later it could be swapped back for your polisy. EDIT: I see just after I typed this Michel responded.

If I had to hazard a guess I would say the serial PLM will never be manufactured again. Look at Insteon's track record and what the guessers are telling us, here. By the time the serial PLM is ready to be manufactured again, there will not be any market left for them. We are constantly being told by the guessers that Insteon is trimming products from their lines that do not sell. Why use stock space fr years on products that do not sell? HCL