X10 Community Forum
📱X10 WIFI => 🗯General Discussion => Topic started by: Tuicemen on September 21, 2018, 11:35:51 AM
-
The main issue with getting things added to the WM100 in a timely fashion seems to be the manufacture and developer telling Authinx things can't be done without a hardware rebuild (which is out of the question) Since Authinx has no one experience in the WM100 communication (which seems to be MQTT) or what the chip is actually capable of doing. They can only say to the manufacture or developer can you look into this again this leads to an even larger wait time for us to see things implemented.
I've told Authinx some things are doable and exactly how to do it which was passed on to the developer.
However I have no real experience in MQTT nor what the chip can actually do, I do have some experience in creating Android apps however.
If Authinx could say to the manufacture or developer Yes you can do that with proof that it can be done I believe development will move much quicker.
I've asked for a list of what the developer is currently telling them can't be done as it requires a hardware change.
My idea of a updateable firmware was to help overcome many issues that would pop up requiring a hardware change.
-
I can't help with the WiFi end, but I can pursue the communication between the daughter board and the motherboard - in particular those lines labeled 232OUT and 232IN.
Jeff
-
Thanks Jeff,
Any Infomation we can supply Authinx will give them some amunition when told something can't be done.
Authinx obiously can't get clear answers from the developer or manufacture .
Theyre told reason something can't be added is always a hardware limitation which I refuse to believe!
There is almost always a firmware or software solution and given it appears the chips resources are not fully utilized I'm sure those could be tapped into.
-
It will be about a week before I have time to pursue this because I'm in the middle of a build cycle. But with the motherboard being based on the PAT03, it may just a X10 powerline interface for standard commands. There is no way a downloadable firmware update will change what the motherboard is capable of.
Jeff
-
In their description of the PAT03, Authinx says it has a new amplifier that gives a PLC output that is 10x that of the PAT01 so it does make sense that the WM100 motherboard is based on it. That was also pretty obvious in the photo of the first version that Tuicemen posted earlier.
It may be that one of the mystery 14-pin ICs provides a serial interface with the daughter board. If so, replacing the daughter board with something like the WeMos D1 Mini Pro that can be programmed using the Arduino IDE and even with the freeware Basic4Arduino (which also supports the ESP8266) could make things easier.
-
There are a few forums dedicated to the ESP chip and even SDKs (yes plural).
I suspect that's all the main board does as well, the chip has upgradeable firmware built in so it is unlikely that is passed to the main board.
Knowing what is actually passed to the main board will help a lot.
-
Knowing what is actually passed to the main board will help a lot.
Give me a week and I should be able to provide some insight. It would be great if it supports the CM11A protocol.
Jeff
-
@Tuicemen I'm assuming the developer is refusing to part with the protocol. I'm also assuming that Autinx has requested it. Could I be as bold as to ask what exactly did Autinx purchase.
I imagine you could pick up MQTT fairly easily. Am I reading this correctly. WM100 revolves around MQTT, a basic short messaging protocol. Are you getting nearer the end game here.
-
The developer has stated they will part with the protocol for a ridiculous sum. Authinx has been trying to negotiate a payment since first app release. The WM100 was I'm told a joint venture with the manufacture and the manufacture looked after getting the developer.
As for MQTT I have looked into it, however I'm not 100% sure that is what is being used as the chip can use a number of different connection methods. MQTT is most commonly used for IOT but there are others.
I need to fire up Wireshark and spend some time watching calls and what is returned.
From that it maybe able to decipher what is actually being sent and received.
Nowhere near the end game but to be honest I've not spent much time with it.
I've asked Authinx for some hardware/software specifics which they attempted to get from the manufacture but I've not heard anything as yet. ::) :'
-
I've asked Authinx for some hardware/software specifics which they attempted to get from the manufacture but I've not heard anything as yet. ::) :'
At the very least the schematics should be made available as they are available for most other X10 products. I don't think anybody is going to go through the trouble of building one themselves from the schematic. That is the same philosophy I had when I released schematics for all the XTB products.
Jeff
-
This subject I hope has woken the sleeping giants.
I'm starting to see that the manufacturer/developer has shafted Authinx. They've got to somehow detach from these guys and take their project back under their own control. I've no idea what they've paid for this arrangement but $1 is $1 too much. I imagine it was a lot more than that.
I suggest that anyone with any influence on this forum talk seriously to Authinx and advise them to walk away from these cash suckers and somehow achieve what they set out to do themselves.
I've no doubt the wise owls on this forum will help guide the way for them.
-
After putting 38 more units on the shelf ready to ship, I had some time today to capture traces going between the daughter board and motherboard. Unfortunately, I have not yet made sense of the bit pattern. It certainly does not adhere to the CM11A protocol as there is only activity on 232_OUT during transmit and on 232_IN during receive. The data pattern is at least 23 bits long with a bunch of trailing zeros after that. I see the 22nd and 23rd bits flip between ON and OFF, but the data patterns do not match ON and OFF for the TW523 protocol.
P1 ON: 00101010110011011001010000... (transmit)
P1 OFF: 00101010110011011001001000... (transmit)
F4 OFF: 01101110110101010011001000... (receive)
It doesn't seem to match ASCII commands because the bit patterns do not match what would be necessary for the unit or device codes. Similarly, the bit patterns do not match the RF protocol either.
What may be required is to exhaustively go through all house, unit, and command codes to see how they map into the bit patterns. Of course, maybe someone else can make sense out of it. Note that "1" means a positive voltage on the respective 232 pin.
Jeff
-
I'm starting to see that the manufacturer/developer has shafted Authinx. They've got to somehow detach from these guys and take their project back under their own control.
I suggest that anyone with any influence on this forum talk seriously to Authinx and advise them to walk away from these cash suckers and somehow achieve what they set out to do themselves.
I think one the problems Authinx has is the WM100 manufacturer is also the manufacturer for ALL X10 products Authinx sells. And I speculate that X10 products is not the only livelihood for this manufacturer. In fact, X10 products may be a small portion of their total output. Otherwise I think the manufacturer would be a lot more cooperative and responsive. Authinx may be between a rock and a hard place.
Of course the increasing tariffs on China imports may spur Authinx into snooping around for another manufacture outside of China. However, (again speculation) I doubt Authinx has any of the schematics, BoMs, component specs, mechanical drawings, etc. etc. etc. for any of the X10 products.
I will be real surprised to see Authinx even whisper about looking elsewhere. Again, Authinx should have hired Dave Rye when they had the chance.
-
After putting 38 more units on the shelf ready to ship, I had some time today to capture traces going between the daughter board and motherboard. Unfortunately, I have not yet made sense of the bit pattern. It certainly does not adhere to the CM11A protocol as there is only activity on 232_OUT during transmit and on 232_IN during receive. The data pattern is at least 23 bits long with a bunch of trailing zeros after that. I see the 22nd and 23rd bits flip between ON and OFF, but the data patterns do not match ON and OFF for the TW523 protocol.
P1 ON: 00101010110011011001010000... (transmit)
P1 OFF: 00101010110011011001001000... (transmit)
F4 OFF: 01101110110101010011001000... (receive)
It doesn't seem to match ASCII commands because the bit patterns do not match what would be necessary for the unit or device codes. Similarly, the bit patterns do not match the RF protocol either.
What may be required is to exhaustively go through all house, unit, and command codes to see how they map into the bit patterns. Of course, maybe someone else can make sense out of it. Note that "1" means a positive voltage on the respective 232 pin.
Jeff
I had hoped for better news :(
-
Progress!
I have exhaustively gone through all house and unit codes and discovered there is a pattern. I apparently skipped a bit when I typed in the pattern yesterday.
A1 ON is 00101010110011001101010000...
Lets expand that: 00101010110 0110 0110 1010000...
In all patterns the first 11 bits have remained the same. Bits 12-15 are the unit code, and bits 16-19 are the house code per the X10 Technical Note.
Command codes are more difficult because I don't see how to make the WM100 issue the full set of 16. I did check ON, OFF, Bright, Dim, ALL ON, ALL OFF, and a pre-set dim. They changed bits 21-29, but the patterns do not match the X10 protocol. The basic commands use bits 22-25, and a pre-set dim command also used bits 26-29.
1000 - ON
0100 - OFF
1110 - ALL OFF
1101 - Bright step
0011 - Dim step
ALL ON just sequenced through individual ON commands for all lights even when on the same house code.
Jeff
-
Progress!
I have exhaustively gone through all house and unit codes and discovered there is a pattern. I apparently skipped a bit when I typed in the pattern yesterday.
A1 ON is 00101010110011001101010000...
Lets expand that: 00101010110 0110 0110 1010000...
In all patterns the first 11 bits have remained the same. Bits 12-15 are the unit code, and bits 16-19 are the house code per the X10 Technical Note.
Command codes are more difficult because I don't see how to make the WM100 issue the full set of 16. I did check ON, OFF, Bright, Dim, ALL ON, ALL OFF, and a pre-set dim. They changed bits 21-29, but the patterns do not match the X10 protocol. The basic commands use bits 22-25, and a pre-set dim command also used bits 26-29.
1000 - ON
0100 - OFF
1110 - ALL OFF
1101 - Bright step
0011 - Dim step
ALL ON just sequenced through individual ON commands for all lights even when on the same house code.
Jeff
You're certainly making progress on that one. At the rate you're progressing you'll have it cracked shortly. That'll be a shot in the arm for the WM100 makers.
-
You're certainly making progress on that one. At the rate you're progressing you'll have it cracked shortly. That'll be a shot in the arm for the WM100 makers.
I've taken this just about as far as I can. I have the data patterns for all house and unit codes as well as all the command codes the WM100 can issue. What I haven't pursued exhaustively are the pre-set dim codes.
Essentially a transmission is a continuous string of 30 bits comprised of 3 words of 10 bits. Data is the middle 8 bits of each 10 bit word:
Word 1: 00101010101 (Always this pattern for transmit - 55 hex - Receive starts with DD hex)
Word 2: 0UUUUHHHH1 (UUUU is the unit code, HHHH is the house code per TW523 spec)
Word 3: 0CCCCBBBB1 (CCCC is the command code, BBBB is brightness added for pre-set dim commands - normally 0's)
CCCC is defined as:
1000 - ON
0100 - OFF
1110 - ALL OFF
1101 - Bright step
0011 - Dim step
The data rate was about 100uS per bit - maybe 9600 baud. (I didn't record the voltage levels.)
Jeff
-
Great work Jeff #:)
One step towards the end user not requiring the cloud to turn on a device. :)%
Thankfully most of use have a palmpad or some other way to control our X10 devices.
Now to see about talking to the wi-fi chip or flashing it to put a custom firmware on it. This may be a bit more of a chore but I'm sure one of the talented members here is up for the chalenge. ;)
-
Now to see about talking to the wi-fi chip or flashing it to put a custom firmware on it. This may be a bit more of a chore but I'm sure one of the talented members here is up for the chalenge. ;)
What Jeff has decoded would likely be serial communications between the MCU and one of the mystery ICs on the mother board. Before flashing the ESP8266 we need to understand communications between it and the MCU.
As for flashing the ESP8266, the ESPBasic interpreter would allow for experimentation.
https://www.esp8266basic.com/flashing-instructions.html (https://www.esp8266basic.com/flashing-instructions.html)
-
What Jeff has decoded would likely be serial communications between the MCU and one of the mystery ICs on the mother board.
Yes, that is exactly what I decoded. It occurred to me that I should also capture the received commands because they have a different pattern in the first word. And using HomeVision, I can issue ALL the possible commands to see which ones are actually implemented in the WM100.
Jeff
-
Well that wasn't too productive. The WM100 motherboard only responded to the basic X10 commands:
1000 -> ON
0100 -> OFF
0011 -> Dim
1101 -> Bright
1110 -> All Units OFF
1010 -> All Lights ON
0110 -> All Lights Off
These were the same data patterns that the daughter board sent for transmission, and they do not match the codes in the X10 Technical spec.
There was no response from the motherboard at all for any of the other 9 basic commands or extended codes.
In another test I monitored the line with the XTBM-Pro while controlling a dimmable module or wall switch. The wall switch can be set directly to a given brightness with an extended code, but the WM100 ramped to the desired level with a series or bright or dim commands. Apparently bits 26-29 tell it how many bright or dim steps to transmit. It never transmitted either the old pre-set dim code or the extended command used by Leviton and newer X10 switches. Essentially, it is no better than a PalmPad in this regard.
Jeff
-
Well that wasn't too productive. The WM100 motherboard only responded to the basic X10 commands:
1000 -> ON
0100 -> OFF
0011 -> Dim
1101 -> Bright
1110 -> All Units OFF
1010 -> All Lights ON
0110 -> All Lights Off
These were the same data patterns that the daughter board sent for transmission, and they do not match the codes in the X10 Technical spec.
There was no response from the motherboard at all for any of the other 9 basic commands or extended codes.
In another test I monitored the line with the XTBM-Pro while controlling a dimmable module or wall switch. The wall switch can be set directly to a given brightness with an extended code, but the WM100 ramped to the desired level with a series or bright or dim commands. Apparently bits 26-29 tell it how many bright or dim steps to transmit. It never transmitted either the old pre-set dim code or the extended command used by Leviton and newer X10 switches. Essentially, it is no better than a PalmPad in this regard.
Jeff
At the risk of sounding a little naive Jeff, is there any features in the WM100 that you couldn't easily replicate yourself. My thinking from this would be, bye bye WM100, hello new concept. It certainly sounds like you couldn't do any worse.
If I'm getting this right, users are looking for a wireless X10 controller capable of issuing and receiving X10 RF commands. Am I being too simplistic with this assumption.
-
Well that wasn't too productive. The WM100 motherboard only responded to the basic X10 commands:
1000 -> ON
0100 -> OFF
0011 -> Dim
1101 -> Bright
1110 -> All Units OFF
1010 -> All Lights ON
0110 -> All Lights Off
These were the same data patterns that the daughter board sent for transmission, and they do not match the codes in the X10 Technical spec.
There was no response from the motherboard at all for any of the other 9 basic commands or extended codes.
In another test I monitored the line with the XTBM-Pro while controlling a dimmable module or wall switch. The wall switch can be set directly to a given brightness with an extended code, but the WM100 ramped to the desired level with a series or bright or dim commands. Apparently bits 26-29 tell it how many bright or dim steps to transmit. It never transmitted either the old pre-set dim code or the extended command used by Leviton and newer X10 switches. Essentially, it is no better than a PalmPad in this regard.
Jeff
I knew the WM100 didn't issue extended commands. I couldn't get the Factory to understand the need for those.
I also expected the mother board to currently only respond to the codes you mentioned though I had hoped for better. Possibly a firmware upgrade may include the other basic commands as well as extended codes.
If I'm getting this right, users are looking for a wireless X10 controller capable of issuing and receiving X10 RF commands. Am I being too simplistic with this assumption.
I believe most users are wishing for PLC and RF (at least recieving) thought the RF will not come from the WM100.
-
At the risk of sounding a little naive Jeff, is there any features in the WM100 that you couldn't easily replicate yourself. My thinking from this would be, bye bye WM100, hello new concept. It certainly sounds like you couldn't do any worse.
If I'm getting this right, users are looking for a wireless X10 controller capable of issuing and receiving X10 RF commands. Am I being too simplistic with this assumption.
With regard to the motherboard, both the XTB-232 and XTB-523 do considerably more in that they support ALL X10 codes, including extended codes. And while the WM100 is much more powerful than prior X10 transmitters, the XTB units deliver even more power.
What I could not duplicate myself is the WiFi communication because that is not my area of expertise. But if someone wanted to develop a WiFi controller front end for the XTB-232, it could easily surpass the capability of the WM100.
As it stands now the WM100 is essentially an enhanced timer combined with a smartphone remote. Since most people today seem to always be within arms reach of their cellphone, maybe that is a good option for today's generation.
Jeff
-
I also expected the mother board to currently only respond to the codes you mentioned though I had hoped for better. Possibly a firmware upgrade may include the other basic commands as well as extended codes.
Since the interface chip on the motherboard only supports the limited command set, a firmware upgrade to the daughter board would not expand the X10 command set without the interface being replaced too. At this point that is a black box without even a part number on it.
Jeff
-
Since the interface chip on the motherboard only supports the limited command set, a firmware upgrade to the daughter board would not expand the X10 command set without the interface being replaced too. At this point that is a black box without even a part number on it.
Jeff
I missed that you were sending the commands directly to the mother board. B:(
So saddly sending or recieving any other command structure isn't possible even though it may be possible for the chip to send those. :( :( A firmware upgrade may allow other options like triggering of scenes but the main board would be limited to seeing/sending commands that it can currently. :(
It may be best to shift attention to integrating this daughter board into something else like your XTB-232, XTB-523 or a improved CM15A ::) :' That is assuming flashing it with a firmware allowing the daughter board to send the correct info to the mainboard of choice is possible.
-
What I could not duplicate myself is the WiFi communication because that is not my area of expertise. But if someone wanted to develop a WiFi controller front end for the XTB-232, it could easily surpass the capability of the WM100.
You also need to deal with timers, macros, etc. which is likely what the EEPROM on the WM100 daughterboard is for.
-
Is it possible to build a pi on an xtb-523? I'm not sure what the GPIO pins are capable of.
-
Is it possible to build a pi on an xtb-523? I'm not sure what the GPIO pins are capable of.
The XTB-523 would require a new layout and a larger package. The interface would also need some redesign.
The XTB-232 would also require a new layout and a large package, but it would be easier because it handles all the critical timing and only needs a 4800 baud serial interface
Jeff
-
A $5 WeMos D1 Mini is all that's needed for a WiFi-to-Serial adapter. It also has a built-in USB-to-Serial adapter. There are numerous stackable shields that add other functionality (e.g. RTC). All that's currently lacking is an EEPROM shield should one want to support timers & macros.
https://diyprojects.io/wemos-d1-mini-esp8266-multi-purpose-card-for-e5/ (https://diyprojects.io/wemos-d1-mini-esp8266-multi-purpose-card-for-e5/)
https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=Wemos+D1+mini+&_sacat=0 (https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=Wemos+D1+mini+&_sacat=0)
-
A $5 WeMos D1 Mini is all that's needed for a WiFi-to-Serial adapter. It also has a built-in USB-to-Serial adapter. There are numerous stackable shields that add other functionality (e.g. RTC). All that's currently lacking is an EEPROM shield should one want to support timers & macros.
With a total re-layout and using squat larger diameter electrolytics it might be possible to provide enough "air rights" for the 34mm x 26mm WeMos daughter board. But I would be concerned about power dissipation in the small sealed package. And it might be difficult to provide the 500mA peak at 3.3V that I read about in the FAQ:
Therefore, your design must provide for a voltage regulator that can provide 500 mA without suffering a drop in the output voltage which is outside the operating specifications.
Jeff
-
I wouldn't do it internally. It's simpler to leave it as an external device powered by a 5V supply, especially if one wants to add shields. It could work with the XTB-232, CM11A and other serial devices.
-
All that's currently lacking is an EEPROM shield should one want to support timers & macros.
The fact that this RTC can accept a microSD should solve the data storage problem:
https://robotdyn.com/wifi-d1-mini-data-logger-shield-rtc-ds1307-with-battery-microsd.html
Jeff
-
I wouldn't do it internally. It's simpler to leave it as an external device powered by a 5V supply, especially if one wants to add shields. It could work with the XTB-232, CM11A and other serial devices.
Multi-package with an external supply is a kludge, and may be something of interest only to hobbyists. I thought we were addressing a device similar to the WM100, but with a controller that supports extended commands, external triggers, and conditional macros. Essentially, it would address all the limitations that the WM100 has.
Jeff
-
Actually an external device that plugged into a controller is what I suggested to Authinx as a WM-Pro.
It would keep costs down, I suggested it have a Male USB data port so it could plug directly into an existing CM15 or a upgraded one with stronger PLC and RF.
It could be made to use an external power supply or (if the controller had power on the connecting port) be powered from the controller port
I don't believe the existing CM15a has power on the USB port.
-
The fact that this can RTC accept a microSD should solve the data storage problem:
Yes and no. I was aware of the SD card shield but they use flash which has a rather limited number of erase/write cycles whereas EEPROM allows for many, many more. That's probably why the WM100 uses EEPROM. Of course you could just replace the SD card when necessary. And, I really have little experience with this - I don't know how frequently timers/macros get modified.
-
I just did a sim and some bench testing. The XTB-232 transformer can provide 500mA with a low-dropout 3.3V regulator and schottky rectifiers. Dissipation at that max load is about 4W spread among the transformer, rectifiers, regulator, and daughter board. From what I read 500mA is the peak demand, and the average load is more like 100mA, which is easily accommodated.
But it sounds like this isn't anything worth pursuing further.
Jeff
-
I don't know how frequently timers/macros get modified.
I would expect that only during a download. So it could be dozens of times during program development, but after that only when changes are needed. Perhaps 100 to 1000 cycles?
In addition to the downloaded program, it might be a good idea to store a map of the system like AHP does But that would only have to be updated when it is cleared or a new device is recognized. I don't think device status must be stored in non-volatile memory as system configuration is lost during a power interruption anyway. Part of any program initialization should be establishing the correct configuration for that time of day when power is restored.
Jeff
-
I just did a sim and some bench testing. The XTB-232 transformer can provide 500mA with a low-dropout 3.3V regulator and schottky rectifiers. Dissipation at that max load is about 4W spread among the transformer, rectifiers, regulator, and daughter board. From what I read 500mA is the peak demand, and the average load is more like 100mA, which is easily accommodated.
I suspect the ESP8266 only reaches the peak when sending WiFi which will be rather minimal in this application. How often does the XTB-232 (or a CM11A) send serial data?
But it sounds like this isn't anything worth pursuing further.
I was under the impression that you were planning to discontinue the XTB line and fully retire. If you are now planning an XTB-ESP, it should also include EEPROM and RTC.
-
I don't know how frequently timers/macros get modified.
I would expect that only during a download. So it could be dozens of times during program development, but after that only when changes are needed. Perhaps 100 to 1000 cycles?
If that's the case, the ESP8266 flash memory might be adequate. The D1 Mini Pro has 16MB and most of that will likely be free.
Or, if physical size is crucial something like this (with 4MB flash) might work.
https://github.com/SmartArduino/SZDOITWiKi/wiki/ESP8266---ESP-F (https://github.com/SmartArduino/SZDOITWiKi/wiki/ESP8266---ESP-F)
or the one used in the WM100 with 4MB.
https://www.gridconnect.com/products/esp-wroom-02-wifi-802-11-module (https://www.gridconnect.com/products/esp-wroom-02-wifi-802-11-module)
-
I suspect the ESP8266 only reaches the peak when sending WiFi which will be rather minimal in this application. How often does the XTB-232 (or a CM11A) send serial data?
The XTB-232 and CM11A send serial data in response to any X10 commands being received over the powerline. And obviously, there is communication whenever the controller wants to issue an X10 command. Then there is the one second heartbeat when the controller is not responding.
I was under the impression that you were planning to discontinue the XTB line and fully retire. If you are now planning an XTB-ESP, it should also include EEPROM and RTC.
I want to get away from the kitting and assembly. But I'm still willing to do design and prototype work if someone else (like Authinx) is interested in taking over the production.
Jeff
-
4 years ago when I tried to play matchmaker between Marmitek (TIP10RF) and Authinx, the latter didn't even have the courtesy to reply to my email so I suspect that's a dead-end street.
-
4 years ago when I tried to play matchmaker between Marmitek (TIP10RF) and Authinx, the latter didn't even have the courtesy to reply to my email so I suspect that's a dead-end street.
Being a TIP10RF user what had you got in mind. A 310mhz version I assume. If that's the case I imagine that could have been fairly straightforward with all the hardwork done already.
-
Being a TIP10RF user what had you got in mind. A 310mhz version I assume. If that's the case I imagine that could have been fairly straightforward with all the hardwork done already.
All it required was a 310MHz SAW Resonator in place of the 433.92MHz one - nothing could be simpler.
-
Being a TIP10RF user what had you got in mind. A 310mhz version I assume. If that's the case I imagine that could have been fairly straightforward with all the hardwork done already.
All it required was a 310MHz SAW Resonator in place of the 433.92MHz one - nothing could be simpler.
Unbelievable. That's just said it all. Instead they decided to reinvent the wheel. Now I'm not one bit surprised they're in the position they are in now.
How difficult would it be to refactor a TIP10RF for 310mhz use. Would it be expensive to retrofit.
-
How difficult would it be to refactor a TIP10RF for 310mhz use. Would it be expensive to retrofit.
Miniturization and Surface Mount Technology make DIY rework difficult these days. As I recall, the SAW resonator was about 5mm x 5mm with contacts under the package. It would require a hot air gun with a vacuum tip and even then there was a risk of dislodging nearby components. Although I had the necessay tools, I decided it was too risky. It was obviously outside the skillset of most X10 users. Cost would have been minimal - just the replacement SAW resonator.
For those in US/Canada wanting WiFi control of X10, it was easy to convert RF transceivers (TM751, RR501, etc.) to 433.92MHz for use with a TIP10RF. That just required installing a through-hole a 433.92MHz resonator into existing solderpads.
It would have been simple to manufature a 310MHz version but would have required FCC testing.
-
I also had suggested a NA version of the TIP10RF in the early stages of the WM100 development to Authinx.
Their idea was always a PLC transmitter and eventually add RF to that once the PLC end was worked out.
The WM100 is no where near what Authinix envisioned for the first version WMs.
The slow app development of this thing is what most users are upset about. (bugs fixes and option adds)
The limitations of the hardware is next on the list (32 device, no extended commands and RF)
-
I also had suggested a NA version of the TIP10RF in the early stages of the WM100 development to Authinx.
Their idea was always a PLC transmitter and eventually add RF to that once the PLC end was worked out.
The WM100 is no where near what Authinix envisioned for the first version WMs.
The slow app development of this thing is what most users are upset about. (bugs fixes and option adds)
The limitations of the hardware is next on the list (32 device, no extended commands and RF)
I think at this stage the WM100 is going as far as it's Oriental masters want it to go. Authinx it appears are now in a bind.
How could anyone seriously ignore an already available concept like the TIP10RF and not take advantage of it with a minor modification as you've explained @dhoustan is beyond me.
Maybe at this stage they'd be a little more receptive to your idea after what they've been through. I wonder would it be possible for them to this in parallel with a seperate manufacturer.
-
I really think Authinex was trying to build a quality product and not cobble something together which would require a pipeline of existing products.
The downfall was to use the manufacturer they did and then form a partnership on the product.
That 50-50 deal may have worked with the old X10/PICO/BSR/Radio Shack/Magnavox/etc, but the times have changed.
-
How could anyone seriously ignore an already available concept like the TIP10RF and not take advantage of it with a minor modification as you've explained @dhoustan is beyond me.
It never really reached the point where I could explain it - they just never responded to my initial email.
Maybe at this stage they'd be a little more receptive to your idea after what they've been through. I wonder would it be possible for them to this in parallel with a seperate manufacturer.
Marmitek has dropped its X10 products and Haibrain, who took on the line, is now out of business so I'm not sure there is anyone to work with. However, a 310MHz TIP10RF paired with the new PAT03 would certainly be a winner.
https://www.x10.com/pat03.html (https://www.x10.com/pat03.html)
-
310MHz TIP10RF paired with the new PAT03 would certainly be a winner.
While that addresses the local control issue we have with the WM100, is doesn't give us an actual controller that could replace the CM15A.
Jeff
-
310MHz TIP10RF paired with the new PAT03 would certainly be a winner.
While that addresses the local control issue we have with the WM100, is doesn't give us an actual controller that could replace the CM15A.
I agree - which is why I'd like to see your XTB-232 paired with a $2 ESP8266 module w/4MB flash + an EEPROM IC + a PIC supervisor.
https://www.aliexpress.com/item/Official-DOIT-ESP-F-Serial-Wireless-WiFi-Transmission-Module-Fully-Compatible-with-ESP8266/32799357027.html?spm=2114.search0104.3.9.9cac5cb5U2SO9W&transAbTest=ae803_4&ws_ab_test=searchweb0_0%2Csearchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449%2Csearchweb201603_60%2CppcSwitch_0&algo_pvid=3d64ed3c-a298-4979-a158-327804184de6&priceBeautifyAB=0&algo_expid=3d64ed3c-a298-4979-a158-327804184de6-1 (https://www.aliexpress.com/item/Official-DOIT-ESP-F-Serial-Wireless-WiFi-Transmission-Module-Fully-Compatible-with-ESP8266/32799357027.html?spm=2114.search0104.3.9.9cac5cb5U2SO9W&transAbTest=ae803_4&ws_ab_test=searchweb0_0%2Csearchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449%2Csearchweb201603_60%2CppcSwitch_0&algo_pvid=3d64ed3c-a298-4979-a158-327804184de6&priceBeautifyAB=0&algo_expid=3d64ed3c-a298-4979-a158-327804184de6-1)
-
Here's a link to the manual for the ESP-F chip.
https://github.com/SmartArduino/ESP/blob/master/UserManualForESP-F_doitV1.pdf (https://github.com/SmartArduino/ESP/blob/master/UserManualForESP-F_doitV1.pdf)
Note the built-in IR. This sends/receives NEC protocol. Hmmm - X10 uses that protocol for RF.
-
While that addresses the local control issue we have with the WM100, is doesn't give us an actual controller that could replace the CM15A.
I agree - which is why I'd like to see your XTB-232 paired with a $2 ESP8266 module w/4MB flash + an EEPROM IC + a PIC supervisor.
Whatever is added has to be a daughter board because there is no way to even squeeze in the smallest ESP8266 on the current PCB. I looked at integrating the Wemos mini last night. The advantage of that is the real time clock could be stacked with it.
There has to be some 5V - 3.3V interfaces - either between the Wemos mini and the PIC or between a 3.3V PIC and the circuitry it drives. I'm not sure everything would fit on the board. Some components might have to be surface mount on the underside. Or perhaps the whole thing could be converted to surface mount for robotic assembly, but I wouldn't do any more than a few prototypes.
I'm not sure what you meant about a PIC supervisor. I thought the Wemos mini would be the controller, and the existing PIC would provide the serial to X10 PLC conversion. The RTC could include the microSD. What else is needed?
Jeff
-
The ESP8266 needs to monitor the WiFi which requires a bit of fancy footwork if it's also overseeing other tasks (e.g. RF). It's probably adequate on its own here but adding the PIC & EEPROM is kinda the ultimate approach.
Another advantage of the WeMos is the USB-serial adapter which might be used for updates to the program and timers/macros.
One major disadvantage of using the flash for timers/macros is you've killed a +$100 piece of hardware if you should wear out the flash. The WeMos with 16MB flash costs about the same as the 4MB model. If you use microSD, it would need a way to change cards without disassembly of the unit.
I have an RTC shield. I might play around with it after I finish my RF proof-of-concept for which I'm awaiting some Protoboard shields.
For the RTC, I prefer the ST M41T81S IC - same pinout,etc. but it records the time when power is lost making it simple to figure out a power outage length.
P.S. The ESP8266 pins have over voltage protection although I'm unsure of the details.
-
Here's where I saw the bit about the ESP8266 pins being protected...
https://hackaday.io/page/2024-esp8266-is-5v-tolerant-after-all (https://hackaday.io/page/2024-esp8266-is-5v-tolerant-after-all)
All digital IO pins are protected from over-voltage with a snap-back circuit connected between the pad and ground. The snap back voltage is typically about 6V, and the holding voltage is 5.8V. This provides protection from over-voltages and ESD. The output devices are also protected from reversed voltages with diodes.
-
Here's where I saw the bit about the ESP8266 pins being protected...
So we may only need resistors on the two digital inputs - serial in and ring indicator. Using the TTL buffer input we can do a direct connect to the serial output too. So that saves a few components. I worked on this again today. The main problem is squeezing in the electrolytics. The low profile one is too high for a double stack with the Wemos and RTC over it. So I need to move the PIC underneath the Wimos to free up room for taller electrolytics.
To put the antenna at the top of the case the USB port will not be accessible. I don't see a problem with the RTC microSD not being accessible without opening the case as that is likely to last the life of the product. And if it wears out, it is really not much more difficult than replacing a cellphone battery.
Bottom line is the Wimos mini looks feasible if we can do the job with just a double stack and nothing needed from the existing XTB-232 other than the serial connection and power.
Jeff
-
I think we can ignore RI. I don't think it is even passed on via WiFi.
http://www.thefullwiki.org/Ring_Indicator (http://www.thefullwiki.org/Ring_Indicator#wikipedia_Floating_RI_interference_in_serial_cables)
-
I think we can ignore RI. I don't think it is even passed on via WiFi.
That is used as a "wake-up" to indicate a X10 message was received and ready for transfer to the computer. So it could be used as an interrupt for the Wemos to divert its attention. I understand it is not sent out via WiFi.
Jeff
-
I'm not sure it's needed with the ESP8266 but, if its only cost is one resistor, I guess planning for it is worthwhile.
-
I can modify an existing XTB-232 to have a 4-wire digital interface that would directly connect to the Wemos using the CM11A "real-time" protocol. The "A5" clock initialization request at power-up could be eliminated because that was only incorporated to be compatible with the CM11A. The modified XTB-232 would not provide 3.3V power for the Wemos.
I can hand that off to someone else who is developing the Wemos X10 controller. Assuming that works, I'll create some prototypes so the Wemos can plug directly into the PCB.
Jeff
-
I think a WeMos on a breadboard connecting to a standard XTB-232 or CM11A should be adequate for development. The D1 Mini Pro has 16MB flash plus a connector for an external antenna (still has the PCB antenna, as well) offers the most versatility and doesn't add much cost. The RTC and Micro SD card shields are available from Amazon.
https://www.amazon.com/gp/product/B077VJWHJ8/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B077VJWHJ8/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1)
https://www.amazon.com/gp/product/B07G2X3V75/ref=ox_sc_act_title_1?smid=AU1MZF5GWKNC5&psc=1 (https://www.amazon.com/gp/product/B07G2X3V75/ref=ox_sc_act_title_1?smid=AU1MZF5GWKNC5&psc=1)
There are multiple development platforms...
LUA and ESP8266Basic are interpreters.
Arduino IDE and Basic4Arduino are compilers (I think). I believe there's also a GCC C compiler.
-
I think a WeMos on a breadboard connecting to a standard XTB-232 or CM11A should be adequate for development. The D1 Mini Pro has 16MB flash plus a connector for an external antenna (still has the PCB antenna, as well) offers the most versatility and doesn't add much cost. The RTC and Micro SD card shields are available from Amazon.
I had looked at the Wemos mini pro, but the current version is too long at 1.9". There would be no room left for the electrolytics.
You would need an actual RS232 interface for the Wemos when using the standard XTB-232 or CM11A rather than connecting directly to its digital lines. But then I don't need to do anything until we know the Wemos can function as a WiFi X10 controller, which is fine with me.
Jeff
-
I had looked at the Wemos mini pro, but the current version is too long at 1.9". There would be no room left for the electrolytics.
There are clones from other sources that have the same form factor as the amateur Mini. ;)
https://www.amazon.com/Mayata-Pro-16-esp8266-wireless-antenna/dp/B07G9HZ5LM/ref=sr_1_12?ie=UTF8&qid=1538403419&sr=8-12&keywords=wemos+d1+mini+pro (https://www.amazon.com/Mayata-Pro-16-esp8266-wireless-antenna/dp/B07G9HZ5LM/ref=sr_1_12?ie=UTF8&qid=1538403419&sr=8-12&keywords=wemos+d1+mini+pro)
Here's a better source...
https://www.ebay.com/itm/WEMOS-D1-Mini-Pro-V1-1-0-16M-Bytes-External-Antenna-Connector-ESP8266-WIFI-IoT/323421972130?hash=item4b4d73a6a2:g:VDwAAOSwp7RbiGfT:sc:USPSFirstClass!41017!US!-1 (https://www.ebay.com/itm/WEMOS-D1-Mini-Pro-V1-1-0-16M-Bytes-External-Antenna-Connector-ESP8266-WIFI-IoT/323421972130?hash=item4b4d73a6a2:g:VDwAAOSwp7RbiGfT:sc:USPSFirstClass!41017!US!-1)
There are many more on eBay but most ship from China.
Also, I forgot it has a ceramic onboard antenna instead of the PCB trace antenna. That reduces the form factor from the one you saw.
-
I had looked at the Wemos mini pro, but the current version is too long at 1.9". There would be no room left for the electrolytics.
There are clones from other sources that have the same form factor as the amateur Mini. ;)
Yes, I had seen them on eBay and Amazon. But they appeared to be similar or identical to the previous discontinued versions of the genuine Wemos mini pro. I didn't think it wise to commit to a discontinued product. Even Authinx ran into a problem with a part being discontinued during the WM100 development.
Jeff
-
One major disadvantage of using the flash for timers/macros is you've killed a +$100 piece of hardware if you should wear out the flash.
The W25Q32FVSS Flash memory used on the Wemos mini quotes:
More than 100,000 erase/program cycles
More than 20-year data retention
It has 16384 256-byte pages (4MB). Finest granularity on erasing is a 4K block, or 16 pages. So that would be an issue modifying macros or timers. One solution is to copy the entire 4K block into RAM, make the change, and then write the 4K block back into flash.
The Wemos mini has its own 3.3V regulator from 5V, so a single 5V regulator can supply both the PIC and the mini.
Jeff
-
That flash life is about 10x what I saw for a generic flash life web query. So that looks good.
The user program is also stored in flash.
https://bbs.espressif.com/viewtopic.php?t=129#p471 (https://bbs.espressif.com/viewtopic.php?t=129#p471)
Am I correct in thinking that all that you need add are the resistors discussed earlier?
-
I have one of the original Pro models which predates Lolin.
https://diyprojects.io/wemos-news-d1-mini-pro-wemos-xi-shield-sht30/ (https://diyprojects.io/wemos-news-d1-mini-pro-wemos-xi-shield-sht30/)
It looks like all that the revised version adds is the battery interface which could be done with a shield.
-
I just remembered a post from brohogan last year and was wondering if anyone attempted to recreate it. This was the link he included http://brohogan.blogspot.com/search/label/Alexa
-
Am I correct in thinking that all that you need add are the resistors discussed earlier?
Not quite. The 5V supply was designed to provide less than 50mA, so that has to be changed. Simulation shows it is easy to get regulated 3.3V off the center tap of the transformer, but not regulated 5V. And unregulated has too much range for the regulator on the mimi. So I may be stuck having to include a 3.3V regulator anyway.
It looks like everything needed will squeeze in, but I'm not going to do the actual layout until we know the concept works.
I'm making the assumption that someone else is going to develop the program residing on the mini. I can still provide a modified XTB-232 that will connect directly to the mini pins just like the final PCB, and can ship that to whomever is developing the mini code.
Jeff
-
I just remembered a post from brohogan last year and was wondering if anyone attempted to recreate it. This was the link he included http://brohogan.blogspot.com/search/label/Alexa (http://brohogan.blogspot.com/search/label/Alexa)
No, but there may be a simpler way to handle the X10 RF without needing the CM17A. I'll try to provide a writeup in a few days.
-
My original Idea for this thread was not to create a new module but that is a good thing if we can do that and in the process make it a far more powerful one.
What I was looking for is what the Wi-Fi chip can do with the current main board or more to the point on its own.
Jeff has discovered the main board is very limited in its X10 abilities which also limites the abilities of the Wi-fi module (x10 signal wise) However most users just want the current WM100 to work as advertised.
Time sync issues shouldn't be a problem nor should local control or the abilitiy for the app to connect to more then one WM100 to me these are basic software programable issues.
Creating a new module is what the factory wants Authinx to say to do.
-
Creating a new module is what the factory wants Authinx to say to do.
But, is it likely that they will want to use Jeff's XTB-232 as the basis for said new module?
-
What I was looking for is what the Wi-Fi chip can do with the current main board or more to the point on its own.
Jeff has discovered the main board is very limited in its X10 abilities which also limites the abilities of the Wi-fi module (x10 signal wise) However most users just want the current WM100 to work as advertised.
What Jeff has exposed is that the developers appear to be braindead. They have ignored basic functionality of the ESP8266 module and seem to have used about 2% of the fuctionality of the ST MCU & EEPROM on the daughter board with the ESP8266.
For example, the ESP8266EX datasheet says...ESP8266EX currently supports one infrared remote control interface.
...
The functionality of Infrared remote control interface can be implemented via software programming. NEC coding, modulation, and demodulation are supported by this interface. The frequency of modulated carrier signal is 38 kHz, while the duty ratio of the square wave is 1/3.
X10 RF uses the same NEC protocol. About 20 years ago, I used similar functionality to convert a Pronto to send 310MHz (or 433.92MHz) X10 RF.
https://www.laser.com/dhouston/pronto.html (https://www.laser.com/dhouston/pronto.html)
Similarly, the IR receive functionality can be used to receive X10 RF merely by inverting the output of an RF receiver. (IR receivers are active-low while RF receivers are active-high.)
-
I'm doubtful that the current factory will use anything we come up with and if they do they'll screw it up.
Jeff as you stated has proven the Factory and Developer are clueless as to x10 and the wi-fi chip.
I realize the things that can be done with the WM100 X10 wise are limited but why not push the wi-fi chip to its limit. Showing that the user base here can do just a good of job as the factory's developer may help Authinx see they are wasting good money better spent on other devices and may even spur them to find another better manufacture.
-
I realize the things that can be done with the WM100 X10 wise are limited but why not push the wi-fi chip to its limit. Showing that the user base here can do just a good of job as the factory's developer may help Authinx see they are wasting good money better spent on other devices and may even spur them to find another better manufacture.
That sounds like a stand down for now. That's fine with me. I spent the day creating a layout for an electronic E Unit. It's more fun to work on that stuff anyway.
Jeff
-
Showing that the user base here can do just a good of job as the factory's developer may help Authinx see they are wasting good money better spent on other devices and may even spur them to find another better manufacture.
If Authinx hasn't figured that out by now then they aren't reading this forum and are truly out of touch.
-
I realize the things that can be done with the WM100 X10 wise are limited but why not push the wi-fi chip to its limit. Showing that the user base here can do just a good of job as the factory's developer may help Authinx see they are wasting good money better spent on other devices and may even spur them to find another better manufacture.
That sounds like a stand down for now. That's fine with me. I spent the day creating a layout for an electronic E Unit. It's more fun to work on that stuff anyway.
Jeff
No ! I'm not suggesting a stand down of any sort.
Nor even A slow down.
Anything better then the Wm100 is progress.
-
No ! I'm not suggesting a stand down of any sort.
Nor even A slow down.
I was referring to my work marrying together a Wemos mini with the XTB-232 motherboard. My expertise is not in WiFi, so somebody else has to carry the WM100 baton. I'll be pretty busy now until next spring anyway.
Jeff
-
I don't think Authinx would be interested in producing any Wi-Fi module prototype we can come up with B:(
Their current troubles with the factory and developer have left a bad taste for producing any new modules. Also this they see is a device for power users, which they say there is no market for. :o
-
Is Authinx owned by Eddie Lampert by any chance? >*< rofl
-
Is Authinx owned by Eddie Lampert by any chance? >*< rofl
What's "Eddie Lampert" in Mandarin?
https://www.bloomberg.com/research/stocks/private/person.asp?personId=1132906&privcapId=598742 (https://www.bloomberg.com/research/stocks/private/person.asp?personId=1132906&privcapId=598742)
-
Their current troubles with the factory and developer have left a bad taste for producing any new modules.
That may be why the little module I designed that allows LED lights to work on 2-wire dimmer switches appears to have died on the vine.
Jeff
-
Their current troubles with the factory and developer have left a bad taste for producing any new modules.
That may be why the little module I designed that allows LED lights to work on 2-wire dimmer switches appears to have died on the vine.
Jeff
There definitely is a communication problem between the factory and Authinx which is frustrating the Owner to no end.
I'd follow up with Authinx to see if they have any word on your little module. It may have just been put on the back burner with the WM100 issues dragging on.