Re: [mh] The Post Insteon World

Giles Godart-Brown <[email protected]> Fri, 17 Jun 2022 18:32:52 +0100
Newsgroups gmane.comp.misc.misterhouse.user
Message-ID <[email protected]>
Bruce

Some replies in-line

Regards

Giles

On 17/06/2022 15:07, Bruce Schaeffer wrote:
> Thanks to all for your ideas on how to move away from Insteon/X10 and 
> suggestions for a replacement environment.
>
> I have found numerous articles and YouTubes regarding Tasmota. A few 
> articles (I didn't keep the references - I should have) seem to say 
> that some devices that used to be able to be reflashed with Tasmota 
> are no longer able to due to changes on the device's chip set. I'm 
> looking for your opinions.
GGB> Not come across this but I haven't bought anything recently.  
Sonoffs are gradually moving over to their DIY platform that means you 
can re-flash without soldering a FTDI bridge.
>
> As far as device replacements, I have found the Sonoff S31 (ASIN 
> B08GKGS197) so I bought one. Along with that purchase, I bought a 
> Moyina FT232 (ASIN B075N82CD) and Goupchn Mini Grabber Test Hooks 
> (ASIN B08M5Z5YF) [to avoid soldering].My plan is to reflash the S31 
> with Tasmota and start playing with it.
>
> The Sonoff S31 appears to be a direct replacement for the Insteon 
> On/Off Module 2635-222 and Insteon ApplianceLinc 2456S3.
>
> I also have the following Insteon modules. What devices are suitable 
> substitutes?
> - SwitchLinc 2477S Wall Switch
> - SwitchLinc 2466SW Wall Switch
> - SwitchLinc 2474DWH Wall Switch [this is being used where there is no 
> neutral wire available]
> - LampLinc Dimmer 2457D2 [similar to On/Off Module 2635-222, but dims 
> via a triac]
GGB> the devices I use in the UK probably aren't relevant.
>
> Now for the Misterhouse part.  I have read ( 
> https://github.com/hollie/misterhouse/wiki/Tasmota ) and have a 
> question about the MHT file.  The article gives two examples, 
> TASMOTA_HTTP_SWITCH and TASMOTA_HTTP_FAN. What other Tasmota device 
> types are there and how are they coded in the MHT file?
>
GGB> Once you get away from switches, you are better off using the MQTT 
route, in which case almost anything is possible by having a device that 
is listening to the Topic the device uses when it changes state or needs 
to be signalled, then Misterhouse will be kept in sync with the value of 
the Topic.
> It appears that I can command devices from Misterhouse via either HTTP 
> or MQTT.
GGB> Yes that's true
> - What are the advantages of one over the other?

GGB> If you want to use MQTT then you will need to run a broker 
e.g.Mosquitto and that's thing to go wrong,

MQTT has many benefits like its 'Last Will and Testament' messages that 
you can intercept to see if a device fails to send its watchdog pings,

You will need to do some JSON decoding to get what you want out of the 
MQTT messages.

I use both - HTML to send on-off commands and MQTT for monitoring and 
LWT checking.

On switches I also have a Tasmota rule to send an http back to 
Misterhouse when someone presses the toggle button on the device to make 
sure that it stays in sync.

> - Can the environment be mixed where some devices are commanded via 
> HTTP and some via MQTT?  Why would I want to do this?

GGB> Yes they can, I use both; HTML for switches and  MQTT for sensors 
especially where they have to send something other than on-off (like a 
temp sensor).

Note that a lot of Sonoff battery powered sensors use Zigbee, so you 
need to use the Sonoff Wifi Bridge to gateway into Misterhouse, I use 
MQTT for this.

The MQTT messages it sends look like this for a PIR;

Topic = tele/Back_hall_zigbee_gateway/SENSOR

Message = 
{"ZbReceived":{"0x2BF1":{"Device":"0x2BF1","Name":"Lounge_zigbee_PIR","0500<00":"010000000000","ZoneStatusChange":1,"Occupancy":1,"Endpoint":1,"LinkQuality":40}}}

In Zigbee speak, Occupancy=1 = Motion.

Or for a wireless temp sensor;

Message = 
{{"ZbReceived":{"0x272B":{"Device":"0x272B","Name":"Downstairs_bathroom_zb_temp","Temperature":26.33,"Endpoint":1,"LinkQuality":61}}}

> - Can HTTPS be used rather than HTTP?
GGB> I don't think so, but I may be wrong.
> - Is there a secure implementation of MQTT?  Can it be used?

GGB> This page gives some more info on securing Tasmota 
https://tasmota.github.io/docs/Securing-your-IoT-from-hacking/

> - The article mentions a MQTT broker for the Raspberry PI (mine is a 
> 4) called "Mosquitto".

GGB> Yes I run Mosquitto on a Pi4

> I may start with HTTP and move to MQTT based on your suggestions.

GGB> Good plan, the MQTT stuff takes a bit of getting used to, but it 
was designed by some very clever engineers at IBM Hersley for monitoring 
oil pipelines. I met them about 20 years ago and its taken me all this 
time to understand why they were so excited about it.

Mosquitto does seem to be very robust, I've only had it behave badly 
(i.e. very slowly) when I had a bug which bombarded it with thousands of 
messages, so my fault really.

If you do take the plunge I recommend you install MQTT.fx 
(https://mqttfx.jensd.de/), its a free MQTT debug tool which you can use 
to send messages as well as sniff what's going on with useful filters.

>
> The Sonoff S31 has power monitoring capabilities (as opposed to the 
> S31 Lite). Can I get this information into Misterhouse so it can make 
> decisions based on power usage?

GGB> The S31 looks like the  UK Sonoff POW. If its the same, then yes, 
you can trap the MQTT messages it sends as the power changes, or screen 
scrape the home page of the device in HTML.

The MQTT the POW sends looks like this;

Topic= tele/Gym_infrastructure/SENSOR

Message = 
{"Time":"2022-06-17T18:12:09","ENERGY":{"TotalStartTime":"2021-03-23T11:10:00","Total":408.911,"Yesterday":0.000,"Today":1.194,"Period":11,"Power":130,"ApparentPower":198,"ReactivePower":149,"Factor":0.66,"Voltage":248,"Current":0.799}}

If you had a device like this (items.mht)

MQTT_DEVICE, Gym_power Group1,group2,etc, mqtt_1, 
tele/Gym_infrastructure/SENSOR

Then Gym_power would be kept up to date with the message string above, a 
bit of JSON decode will get the data out of it nicely.

> Your ideas and experiences are always valued.
>
> Thanks,
> Bruce
>
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> 
> 	Virus-free. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> 
>
>
>
> On Sun, May 15, 2022 at 12:17 PM Bruce Schaeffer 
> <[email protected]> wrote:
>
>     I'm looking for suggestions on how to move forward in a "post
>     Insteon" world.
>
>     My own environment is a Raspberry Pi connected to a PowerLinc
>     2413U running Misterhouse. The end devices are a mix of Insteon
>     with X10 controllers. I "translate" X10 signals to Insteon
>     commands within MH.
>
>     The PLM and Raspberry PI are less than a year old. I had plans to
>     purchase a backup PLM, but it didn't happen. I see now it's no
>     longer an option.
>
>     I would like to migrate from Insteon (and maybe X10) to something
>     that is more modern; keeping MH on the Pi as the main "server". 
>     My MH programming has more than 20 years of effort.
>
>     I have read that MH is able to utilize technologies other than X10
>     and Insteon.
>
>     What direction are you folks leaning towards that is able to be
>     controlled with MH and is still in business?
>
>     Please include hardware requirements for each suggested protocol
>     so I can begin working on a budget.  If your suggestion is also
>     able to run Insteon devices, all the better. I don't expect that
>     to be the case since the Insteon protocol was proprietary.
>
>     The optimum situation would be for me to first purchase whatever
>     controller is needed for the new protocol (the device that would
>     eventually replace the Insteon PLM), get it talking to MH. I'd
>     like to think that MH would be able to talk to both PLMs.  Then
>     I'd start purchasing end devices that would replace my existing
>     Insteon end devices.
>
>     Your suggestions would be very welcome.
>
>     Thanks,
>     Bruce
>
>
>
> ________________________________________________________
> To unsubscribe from this list, go to:https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users