mmb Posted August 6, 2021 Posted August 6, 2021 I'm running ISY/Polisy with an Insteon switch, a Lamplinc and a simple Program to turn the LL on every hour with a wait of 30 minutes then an off (24x7) I checked the event log this morning for no good reason and noticed i have about 12,000 or so of the X10 events per attached. Is this a known problem? Not urgent of course just curious. Thanks
Michel Kohanim Posted August 6, 2021 Posted August 6, 2021 @mmb, These are X10 messages sent by something other than ISY (or perhaps they are responding to ISY). With kind regards, Michel 1
mmb Posted August 6, 2021 Author Posted August 6, 2021 Interesting, I'll have to think about that one as I don't have anything X10 that I know of... Thanks!
mbking Posted August 8, 2021 Posted August 8, 2021 I'm seeing some unexpected behavior in the ISY on Polisy log file as well. Not only am I seeing some X10 activity I don't expect to see, but my time stamps are incorrect. I have one dimmer added with a single program set to turn it on and off. That is working as expected. Not sure why the time stamps are incorrect, though. Times in the Admin Console look OK. I forgot to factory reset the dimmer switch before adding it, so I will do that to see if it eliminates the X10 entries. I've received some items from Smarthome that are not factory reset and this could explain the X10 entries. Any thoughts on the time stamp issue?
MrBill Posted August 8, 2021 Posted August 8, 2021 8 hours ago, mbking said: I'm seeing some unexpected behavior in the ISY on Polisy log file as well. Not only am I seeing some X10 activity I don't expect to see, but my time stamps are incorrect. I have one dimmer added with a single program set to turn it on and off. That is working as expected. Not sure why the time stamps are incorrect, though. Times in the Admin Console look OK. I forgot to factory reset the dimmer switch before adding it, so I will do that to see if it eliminates the X10 entries. I've received some items from Smarthome that are not factory reset and this could explain the X10 entries. Any thoughts on the time stamp issue? Have you updated to v5.0.4? On 8/1/2021 at 4:20 PM, Michel Kohanim said: 2. Stopped our experimentation with time travel ... so, the logs will now have the correct timestamp (the old entries will continue having wrong timestamps). Also, separated error log from system messages. So, now there's a different log file (SYSOUT.LOG) capturing isy operational messages
mbking Posted August 8, 2021 Posted August 8, 2021 Yes, I’m on 5.0.4. Sent from my iPhone using Tapatalk
Michel Kohanim Posted August 8, 2021 Posted August 8, 2021 @mbking, The date was an issue we fixed in 5.0.4. But, older log entries were not fixed. So, you will see those. With kind regards, Michel
mbking Posted August 8, 2021 Posted August 8, 2021 @Michel Kohanim, I've been clearing the log before initiating a few events to see if the date and time is correct and it is still giving me the same results. To be clear, I'm looking at the Log file under Tools in the Admin Console for the ISY on Polisy. I took a quick look at the Error Log and it seems to have the correct date and time. I've verified that I have Polisy v5.0.4 firmware per the display under Help->About in the Admin Console. While experimenting with this issue this afternoon, I noticed that while the date and time were correct in the Admin Console display, my time zone was not. The Admin Console showed Los Angeles and my Polisy setting is Austin, TX. The sunrise and sunset where off as well. I went into the Polisy Console and changed my location to San Antonio, TX and then back again to Austin, TX. I then did a "sudo service isy restart" and now the location and sunrise and sunset are correct in the Admin Console for ISY on Polisy. I have the one dimmer controlled by a single program and that program fires at the correct times in the If statement. It's just the time stamps in the log file that I'm having issues with. Anything else I should try to fix the time stamps? Mark
mmb Posted August 9, 2021 Author Posted August 9, 2021 I was seeing the same problem but the update fixed my timestamps. Did you reboot your ISY/Polisy?
mbking Posted August 9, 2021 Posted August 9, 2021 @mmb, Yes, I rebooted the Polisy box and for good measure, restarted the ISY service. No luck yet. It's a minor issue right now, the ISY service is working. I must have an issue with the installation somewhere. Maybe a future update will fix whatever irregularity I have. Mark
Michel Kohanim Posted August 9, 2021 Posted August 9, 2021 @mbking, This is not a minor issue. For ISY to get datetime/zone/network information, it must communicate with udx. If you do not see the correct timezone in the Admin Console, then there's something very wrong. Also, the IP address comes from udx. So, maybe udx is not running? (do you get the correct IP address in Configuration tab)? With kind regards, Michel
mbking Posted August 9, 2021 Posted August 9, 2021 @Michel Kohanim, The IP address in the Configuration tab is correct and I checked the UDX service and it's running. When I first installed ISY on Polisy, the day, date, and time in the upper left corner of the Admin Console appeared to be correct. The only issue I saw was that program events fired about 20 seconds ahead of what was programmed based on the displayed time. The program summary, though, indicated the event fired at the correct time. I reboot of Polisy corrected that problem. But the time zone was incorrect. It displayed USA, CA, Los Angelos instead of USA, TX, Austin which is what's stored in the Polisy settings. I decided to change the time zone in Polisy to San Antonio, TX and then back to Austin. That did not fix the issue in the Admin Console. But they are actually the same (-6) zone. So I then changed the time zone to a city with a (-7) zone and then back to Austin. This fixed the problem in the Admin Console. I now have the correct time zone displayed as well as correct sunrise and sunset. Not sure if this is related to the issue in the log, but I thought I'd mention it since it seems to be related to communication with UDX. If there are any tests or commands you'd like for me to run, I'll be happy to. Even if I have to start over installing ISY, I can. Just let me know. My configuration is small. Thanks, Mark
Michel Kohanim Posted August 9, 2021 Posted August 9, 2021 @mbking, Changing timezone in Polisy does not automatically change the timezone/DST offset in ISY. You need to restart ISY (Admin Console | Configuration tab | Reboot). Apart from the time zone, what else is the issue? With kind regards, Michel
mbking Posted August 9, 2021 Posted August 9, 2021 @Michel Kohanim, The only remaining issue I have is an incorrect time stamp in the ISY Log file. All time stamps, including new ones, are: Mon 1900/01/01 12:00:00 AM I did a Reboot from the Configuration tab, but this did not fix the time stamp issue. Mark
Michel Kohanim Posted August 9, 2021 Posted August 9, 2021 @mbking, Are you using ISY Portal to check the logs or are you retrieving from the Admin Console? If the Admin Console, then are you certain you're on 5.0.4 (Help | About)? Are you using Admin Console (LAN) or Admin Console (Cloud)? The reason for all these questions, I cannot reproduce it AT ALL. With kind regards, Michel
mbking Posted August 9, 2021 Posted August 9, 2021 @Michel Kohanim, I'm retrieving the log from the Admin Console and using Admin Console(Cloud). Here's my About:
mbking Posted August 9, 2021 Posted August 9, 2021 @Michel Kohanim, Update: If I use Admin Console(LAN), the log in the Admin Console has the correct event times. Mark
Michel Kohanim Posted August 9, 2021 Posted August 9, 2021 @mbking, That was the issue. It's fixed. Thank you. With kind regards, Michel 1
mmb Posted August 9, 2021 Author Posted August 9, 2021 (edited) On 8/6/2021 at 12:31 PM, Michel Kohanim said: @mmb, These are X10 messages sent by something other than ISY (or perhaps they are responding to ISY). With kind regards, Michel <<<<<<<<<Not sure if you're interested but after a lot of work I tracked down the culprit Insteon device - a Lamplinc went rogue. I have several of them so I Reset all of the modules then Restored and that seems to have fixed the problem>>>>>>>>>>>> Scratch that, they're back, so aggravating! Edited August 10, 2021 by mmb
mbking Posted August 9, 2021 Posted August 9, 2021 @mmb, I did the same thing and that seems to have eliminated the X10 messages in the log. The switch I'm using for testing is a new switch from Smarthome, but I've learned that items from Smarthome are not always "factory fresh". I was in a hurry to try out the new ISY on Polisy and skipped the factory reset before installing the test switch. I recommend everyone "Factory Reset" the Insteon devices they buy. Mark
mmb Posted August 10, 2021 Author Posted August 10, 2021 3 hours ago, mbking said: @mmb, I recommend everyone "Factory Reset" the Insteon devices they buy. Mark I tried to reset my current PLM and it seemed to go well but it didn't stop the X10 messages. Baffling...
larryllix Posted August 10, 2021 Posted August 10, 2021 11 hours ago, mmb said: I tried to reset my current PLM and it seemed to go well but it didn't stop the X10 messages. Baffling... I had some odd X10 signals "perceived" in my ISY994 / PLM. Apparently certain house/unit code signals are very easily interpreted from powerline noise. IIRC X10 signals are supposed to have some security used but apparently the proofing is ignored. 1
MrBill Posted August 10, 2021 Posted August 10, 2021 (edited) 58 minutes ago, larryllix said: I had some odd X10 signals "perceived" in my ISY994 / PLM. Apparently certain house/unit code signals are very easily interpreted from powerline noise. House Code M and Device code 13 are both prone to power line noise, with M13 itself being double scary, as well as All Off, the 4 bit binary code for each is 0000. M13 ON would translate to 0000 00000 0010 (unit code have a 5th 0 bit or M All Off 0000 0000 (where X is any unit code) 58 minutes ago, larryllix said: IIRC X10 signals are supposed to have some security used but apparently the proofing is ignored. There was no checksum, parity bit or anything else. There was a start code which was often represent as 1110 in writeups but it was really 3 active 0-crossings followed by 3 inactive 0-crossings whenever that occurs in noise, the following 0-crossings are interrupted as bits of an X-10 message... as you can see M and 13 and All off where easy to represent as 0000's (I wrote an early X10 software for the Novation Apple Cat modem. Optionally both a DTMF decoder chip and an X10 transceiver could be added to the blazing 1200 Baud modem, later it was available at 2400 baud. I got as far as being able to dial my modem line, hear a beep and enter some DTMF (touchtones) from the phone dial and have some lights turn on or off. No software whatsoever existed for either of the options, you had to read and write the modem registers directly. I tried to combine that with a commercial software package available for the Novation modem at the time called TAM, for Telephone Answering Machine. TAM used a 3rd party voice synthesizer for the outgoing message and then actually activated a cassette tape recorder to record an inbound callers message. Thanks for the trip down memory lane... that was early 80's) Edited August 10, 2021 by MrBill 3
larryllix Posted August 10, 2021 Posted August 10, 2021 29 minutes ago, MrBill said: House Code M and Device code 13 are both prone to power line noise, with M13 itself being double scary, as well as All Off, the 4 bit binary code for each is 0000. M13 ON would translate to 0000 00000 0010 (unit code have a 5th 0 bit or M All Off 0000 0000 (where X is any unit code) There was no checksum, parity bit or anything else. There was a start code which was often represent as 1110 in writeups but it was really 3 active 0-crossings followed by 3 inactive 0-crossings whenever that occurs in noise, the following 0-crossings are interrupted as bits of an X-10 message... as you can see M and 13 and All off where easy to represent as 0000's (I wrote an early X10 software for the Novation Apple Cat modem. Optionally both a DTMF decoder chip and an X10 transceiver could be added to the blazing 1200 Baud modem, later it was available at 2400 baud. I got as far as being able to dial my modem line, hear a beep and enter some DTMF (touchtones) from the phone dial and have some lights turn on or off. No software whatsoever existed for either of the options, you had to read and write the modem registers directly. I tried to combine that with a commercial software package available for the Novation modem at the time called TAM, for Telephone Answering Machine. TAM used a 3rd party voice synthesizer for the outgoing message and then actually activated a cassette tape recorder to record an inbound callers message. Thanks for the trip down memory lane... that was early 80's) The M13 sounds familiar from my PLM code memoirs. IIRC X10 was supposed to transmit the code and then retransmit the code in reverse bits. I always thought it must have never been decoded though as so many random things could trigger X10 devices. I wrote a VB program to decode X10 signals and used it to debug one of the Smartenit? bridge stye devices, decades later. That is where I found it to produce really stupid things and returned it as a manufacturing defect. IIRC the user could never see the reverse transmission as it didn't get out of the X10 bridge devices to the serial ports. hmmmm...been a long time now. I never got past some of the special X10 sequences and it would confuse my software, right out of sync. I would love to do the same for a PLM with Insteon and watch from a third PoV.
mmb Posted August 11, 2021 Author Posted August 11, 2021 On 8/9/2021 at 8:15 PM, mmb said: I tried to reset my current PLM and it seemed to go well but it didn't stop the X10 messages. Baffling... So I replaced it with a new PLM V2.4 and everything is working perfectly. I hope the new USB PLMs don't have this X10 "feature". 1
Recommended Posts